In a Unix system (where the epoch is 00:00:00 UTC, January 1, 1970) running in Rio de Janeiro (which is three hours west of Greenwich), we have the following examples:
То есть дальше идут циферки для Рио, где все поголовно в белых штанах.
Там в сорцах (одинаковых в 53 и 51) просто вызывается сишная mktime, а она смотрит на зону, так что по идее так и должно быть, точно ли 51 не смотрела?
os_time берет секунды и первым делом отсчитывает от них часовой пояс. Если взять 0, то при часовом поясе европа получается 1969 год и луа огорчается.
касаемо 5.1. Не замечалось. Быстрее всего там была возможность работать с отрицательным юникстиме без преобразования os.date. в 5.3 решили навести порядок и при пересборке своих скриптов в режиме ВУИГП (проверках всего и вся) я и увидел эту шляпу.
Часовой пояс, как бы, ни при чём. В 5.1 если дата была меньше 0, os.time возвращал nil, с которым в общем-то можно было работать. В 5.3 в этом случае вы увидите "time result cannot be represented in this installation".
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: В 5.1 если дата была меньше 0, os.time возвращал nil, с которым в общем-то можно было работать.В 5.3 в этом случае вы увидите "time result cannot be represented in this installation".
Это да, смотрим сорец 53 и сравниваем с 51. Но в примере-то из документации не нил возвращается, а вполне себе циферка, зона имеет значение.
Цитата
s_mike@rambler.ru написал: os_time берет секунды и первым делом отсчитывает от них часовой пояс. Если взять 0, то при часовом поясе европа получается 1969 год и луа огорчается.
Так и я о том. Рио плюс три часа, когда там первое января 1970, полночь, в гринвиче уже первое января три часа ночи. А в европе минус час, когда там полночь первого января, тогда, совершенно верно, в гринвиче еще 11 вечера 31 декабря 1969, вот и фейлит. Что забавно, сама mktime считает в диапазоне на год шире, как раз ради таймзон, а потом проверяет, попала ли в допустимый по стандарту диапазон. То есть она внутри сначала сосчитала правильно, а потом вернула ошибку, "ибо нефик".
Я так понимаю, вопрос возник, когда в os.time() был передан какой-нибудь квиковский datetime = {year=1601, month=1, day=1, hour=0} Если в 5.1 тут возвращался nil, и с ним можно было работать, то теперь перед вызовом os.time надо проверить, как минимум год, чтобы не получить исключение
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: вопрос возник, когда в os.time() был передан какой-нибудь квиковский datetime
В первом сообщении ссылка, там пример с полночью первого января 1970 и у них в Рио получилось 10800 (как раз 3 часа), а у Майка вылетел эксепшен. Или заранее проверять, или в pcall и проверять в случае исключения. Кстати говоря, в связи с другой темой озаботился, насколько pcall тормозной. Попробовал экспортнуть всю ТВС простыми call против pcall на каждой строке, результат 18 секунд против 23. В реальном времени можно не париться о ней.
Еще плюсик изучения сорцев, теперь 53 и переданную табличку модифицирует, в 51 оставалась как была.