Комментарии 216
35. Одно и то же время может быть только один раз.
36. Разница (длительность) между временем окончания чего-либо и началом не может быть отрицательна ;)
37. Ну ладно, но отрицательная длина интервала не быть больше часа и бывает такое только раз в год.
tomorrow = time.strftime('%Y/%m/%d', time.localtime(time.time()+86400))
Оно может скакнуть назад разово при старте ОС, если включен ntpclient, который как раз выставляет время моментально. Хотя, даже его можно запустить с ключиком -B, который выполнит плавную коррекцию времени.
Так что, отрицательная длина бывает на не линуксах.
А это перевод. :-)
Для того, чтобы не пропускать метки — надо узнать, что их несколько, а чтобы узнать, что меток несколько — надо не пропускать их мимо глаз.
искал внизу статьи ссылку на оригинал или просто указание что перевод
не нашел, решил что не перевод
а ы вона куда это засунули, в начале статьи в зголовок еле заметным цветом
теперь когда вооружен надеюсь смогу быстро это находить
Ну если даже искали — так чего же не нашли? Она ведь там есть, слева от слова «alizar».
Месяц всегда начинается и заканчивается в тот же год. Или я чего-то не понимаю?
Ответа на ваш вопрос я дать не могу, но про китайский календарь вроде все знают. Если о реализации, то хотя бы вот вам ссылочка: lv.php.net/calendar
В некоторых китайских календарях год может начинаться в разные месяца + есть нечто кроме число-месяц-год, есть ли календари, в которых новый год в середине месяца — не знаю.
В теории-то возможно всё, вот только это имеет значение лишь для функций time_t <-> char*. Вуаля, система ничего не знает о разных календарях.
Что, нет?
php -r "echo phpversion(), PHP_EOL, strtotime('31-12-2008 23:59:59UTC'), PHP_EOL, strtotime('31-12-2008 23:59:60UTC'), PHP_EOL, strtotime('01-01-2009 00:00:00UTC'), PHP_EOL;"
5.3.8-pl0-gentoo
1230767999
1230768000
1230768000
Не бывает. Ее невозможно измерить средствами современных ЭВМ, поэтому в ЭВМ этих секунд нет. Просто в какой-то момент можно зафиксировать, что время системы отличается от координированного времени на секунду. А почему это произошло, из-за обыкновенной погрешности или из-за координации, невозможно. А то, что нельзя измерить, тем можно пренебречь.
Программы, которые падают от незначительной корректировки системных часов по NTP просто неправильно написаны. Для таких целей, где важно не зависеть от перевода часов, есть специальные средства, основанные на монотомном счетчике. Этот счетчик не показывает дату, не показывает часы, он просто отсчитывает периоды. Вот его и надо использовать в таких программах, где важна последовательность событий с точностью до секунды.
Причём возможно, это далеко не худший способ функционирования подобных программ. Ведь если, в качестве альтернативы, считать рабочие часы, привязавшись к какой-то одной конкретной временной зоне, то могут появиться другого рода «ошибки». Например, если человек улетит на другой край планеты, то его работа начнёт регистрироваться ночью — e.g., 4 часа до полуночи, 4 после. Часть рабочих часов и на выходные так сможет ненароком попасть.
Я в таком случае просто брал и считал секунды от начала работы и до окончания, затем слал полученное число и с ним уже работал на сервере, чтоб не было привязки к временным зонам, вот у меня был на самом деле таймер =)
При длительных перелетах можно засечь релятивистское замедление времени.
Фраза «В феврале всегда 28 дней.» означает, что в феврале ровно 28 дней, не меньше и не больше(!).
А значит, этот пункт имеет место быть в списке ложных утверждений.
Ты же переделал её в более мягкую форму, допуская другое количество дней.
35) На машине пользователя всегда будут актуальные обновлённые таймзоны.
Особенно тяжко в этом отношении девайсам на всяких экзотических ОС, для которыми обновления если и выпускаются, то часто никто не утруждается их установкой. Впрочем, то же по большей части относится и к популярным мобильным платформам.
И получается, что чтобы грамотно реализовать идею минимального ущерба при этих действиях, нужно написать кода больше, чем сама система. Зачем? Вот в Angry Birds тоже время считается, и в тетрисе. И нормально. А для аккуратной реализации всех перечисленных 30+ пунктов нужно больше работы, чем для реалистичного полета курицы.
Поэтому мне кажется, что более грамотно не пытаться делать нож, которым нельзя порезаться, если вдруг пользователь-админ решит его в задницу засунуть, а просто написать в условиях, что, скажем, клиент и сервер должны синхронизировать время раз в час. При этом система должна «терпеть» небольшую разницу во времени между ними, а в случае невероятной разницы (разные года) — просто не умирать, но имеет право и не работать. Ну не может программный продукт воевать с его администратором и победить. Если уж администратор хочет что-то запороть — у него это получится. Поэтому и лишние затраты на такую оборону — не нужны.
36. У человека всегда есть дата рождения.
36а. У человека есть хотя бы месяц или год рождения.
37. Любой документ (паспорт гражданина и т.п.) всегда содержит даты, которые реально существуют в календаре.
Я для себя вывел правило — если какие-то даты вводятся в систему из документов, которые приносит гражданин, то надо быть готовым к тому, что эти даты будут неполные (только месяц и год, например) или несуществующие.
Что-то мне подсказывает, что далеко не везде, а в основном только там, где время вводят в ИС, проверяющих дату на валидность в принципе. Либо там где очень внимательные и при этом злые операторы.
Бабушке по отцу в документах писали то Григорьевна, то Георгиевна.
«Подумаешь какая разница, Гриша или Жора был отец!» — видимо думали они. Потом несколько раз приходилось доказывать, что не верблюд…
При регистрации собственности — неверно написали родственные отношения у отца и его тётки. В итоге при вступлении в наследство пришлось доказывать, что он именно ПЛЕМЯННИК, т.к. в написанном была вообще какая-то вода на киселе.
И т.д. и т.п.
Это сейчас проблем нет, а если чего — могут возникнуть на пустом месте, типа каких-нить льгот (или наоборот) в зависимости от возраста…
— свидетельство о рождении 1915 года
— договор 1920 года
— приказ 1940 года
Такая очередь будет постоянно расти, но пока что мощности сервера хватает, а потом плановый апгрейд и при этом всем вроде кажется что система работает нормально:
1. Обычные пользователи получают свои данные
2. Необычные (с 31.06) не получают, но понимают, что сами виноваты, и не бузят, сначала идут исправлять эту ошибку
3. Программисты видят что в системе есть ошибка, но считают что она неважная, поскольку их workaround вроде как все исправляет.
"… У человека только ОДНА дата рождения"
У меня у обоих дедов по две даты рождения: одному на войну хотелось и он её слегка не ту сказал в военкомате, а у второго — в детдоме офф-документы посеяли и написали от балды, не подумав спросить у ребёнка…
37.а Любой документ отражает дату рождения относительно точно
Отцу в документах на участок умудрились лишнюю сотню лет приписать…
36) Миллисекундный таймер в 32х битном регистре никогда не переполнится и его значение всегда будет монотонно возрастать.
Ну и очевидная проблема с переполнением. Сервер может отлично работать пока счетчик не переполнится, а потом какой-нибудь драйвер сходит с ума (например, отдал команду жесткому диску на чтение, нужно прочитать ответ через 10j а время, которое было бы на 10j больше максимально возможного числа в счетчике — почему-то не наступает).
Решили проблему красиво — ну естественно «административно» признали, что любой код ядра обязан корректно обрабатывать переполнение этого счетчика, и затем начали инициализировать его в -300 секунд. Jiffies начинаются не с нуля, а с очень большого числа, а через 5 минут оно переполняется, и все глючные драйвера тут же сыпятся. Что позволяет тратить 5 минут на один тест, а не полгода.
Так сделано, чтобы можно было корректно обрабатывать периодически добавляемые (в последний день года, непосредственно перед полуночью, как, например, в 2008, либо 30 июня) високосные секунды.
Кстати, в следующий раз високосная секунда будет добавлена в этом году, 30 июня, то есть через 11 дней.
The International Earth Rotation and Reference Systems Service (IERS) in Paris — the grand arbiters of time on our big blue marble — has declared that a leap second will be introduced on 30 June, 2012.
Так что можно будет открыть подходящие часы и понаблюдать, как они покажут 23:59:60 — в случае с UTC-часами. Поскольку високосная секунда каждый раз прибавляется в одно и то же время по всему миру, в других местах это может быть не в 23 часа.
Unlike leap days, UTC leap seconds occur simultaneously worldwide; for example, the leap second on December 31, 2005 23:59:60 UTC was December 31, 2005 18:59:60 (6:59:60 p.m.) in U.S. Eastern Standard Time and January 1, 2006 08:59:60 (a.m.) in Japan Standard Time.
некоторые вирусы помечали инфицированные файлы датой с такими секундами.
zdump -v /etc/localtime|grep 2012
/etc/localtime Sat Jun 30 23:59:60 2012 UTC = Sun Jul 1 03:59:60 2012 MSK isdst=0 gmtoff=14400
/etc/localtime Sun Jul 1 00:00:00 2012 UTC = Sun Jul 1 04:00:00 2012 MSK isdst=0 gmtoff=14400
zdump -v /etc/localtime|grep :60
/etc/localtime Fri Jun 30 23:59:60 1972 UTC = Sat Jul 1 02:59:60 1972 MSK isdst=0 gmtoff=10800
/etc/localtime Sun Dec 31 23:59:60 1972 UTC = Mon Jan 1 02:59:60 1973 MSK isdst=0 gmtoff=10800
/etc/localtime Mon Dec 31 23:59:60 1973 UTC = Tue Jan 1 02:59:60 1974 MSK isdst=0 gmtoff=10800
/etc/localtime Tue Dec 31 23:59:60 1974 UTC = Wed Jan 1 02:59:60 1975 MSK isdst=0 gmtoff=10800
/etc/localtime Wed Dec 31 23:59:60 1975 UTC = Thu Jan 1 02:59:60 1976 MSK isdst=0 gmtoff=10800
/etc/localtime Fri Dec 31 23:59:60 1976 UTC = Sat Jan 1 02:59:60 1977 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Dec 31 23:59:60 1977 UTC = Sun Jan 1 02:59:60 1978 MSK isdst=0 gmtoff=10800
/etc/localtime Sun Dec 31 23:59:60 1978 UTC = Mon Jan 1 02:59:60 1979 MSK isdst=0 gmtoff=10800
/etc/localtime Mon Dec 31 23:59:60 1979 UTC = Tue Jan 1 02:59:60 1980 MSK isdst=0 gmtoff=10800
/etc/localtime Tue Jun 30 23:59:60 1981 UTC = Wed Jul 1 03:59:60 1981 MSD isdst=1 gmtoff=14400
/etc/localtime Wed Jun 30 23:59:60 1982 UTC = Thu Jul 1 03:59:60 1982 MSD isdst=1 gmtoff=14400
/etc/localtime Thu Jun 30 23:59:60 1983 UTC = Fri Jul 1 03:59:60 1983 MSD isdst=1 gmtoff=14400
/etc/localtime Sun Jun 30 23:59:60 1985 UTC = Mon Jul 1 03:59:60 1985 MSD isdst=1 gmtoff=14400
/etc/localtime Thu Dec 31 23:59:60 1987 UTC = Fri Jan 1 02:59:60 1988 MSK isdst=0 gmtoff=10800
/etc/localtime Sun Dec 31 23:59:60 1989 UTC = Mon Jan 1 02:59:60 1990 MSK isdst=0 gmtoff=10800
/etc/localtime Mon Dec 31 23:59:60 1990 UTC = Tue Jan 1 02:59:60 1991 MSK isdst=0 gmtoff=10800
/etc/localtime Tue Jun 30 23:59:60 1992 UTC = Wed Jul 1 03:59:60 1992 MSD isdst=1 gmtoff=14400
/etc/localtime Wed Jun 30 23:59:60 1993 UTC = Thu Jul 1 03:59:60 1993 MSD isdst=1 gmtoff=14400
/etc/localtime Thu Jun 30 23:59:60 1994 UTC = Fri Jul 1 03:59:60 1994 MSD isdst=1 gmtoff=14400
/etc/localtime Sun Dec 31 23:59:60 1995 UTC = Mon Jan 1 02:59:60 1996 MSK isdst=0 gmtoff=10800
/etc/localtime Mon Jun 30 23:59:60 1997 UTC = Tue Jul 1 03:59:60 1997 MSD isdst=1 gmtoff=14400
/etc/localtime Thu Dec 31 23:59:60 1998 UTC = Fri Jan 1 02:59:60 1999 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Dec 31 23:59:60 2005 UTC = Sun Jan 1 02:59:60 2006 MSK isdst=0 gmtoff=10800
/etc/localtime Wed Dec 31 23:59:60 2008 UTC = Thu Jan 1 02:59:60 2009 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Jun 30 23:59:60 2012 UTC = Sun Jul 1 03:59:60 2012 MSK isdst=0 gmtoff=14400
Как это так получается, что с 1973 года по 1979 год (включительно) високосные секунды случалися каждый год, с 1983 года по 1989 год — каждый второй год, с 1992 года по 1998 год — опять каждый год (кроме 1996 года), а затем вдруг
Что за астрономические силы прекратили тормозить вращение планеты на целых семь лет?
Или это в Матрице тормозильник сглючил?
Навеяно статьёй с названием типа «За три дня до Рамадана»
??) setTimeout(function(){},1000) сработает через одну секунду.
Мы по работе часто вынуждены считать ОЧЕНЬ точно, так что юзаем mmTimer и тики процессора от запуска программы…
Поэтому обеспечить выполнение некоего кода послезавтра в 12:00:00.000 +- 0.001 с средствами Windows фактически невозможно. Это приводит к весьма своеобразным велосипедам при разработке систем телеметрии — доводилось сталкиваться слегка…
Только подумай — надеется, что наш вид протянет еще десять
миллионов лет,- как будто человек так же приспособлен к жизни,
как черепаха!- Он пожал плечами.- Что ж — может, люди и дотянут
до десятимиллионного года — из чистого упрямства. Как ты
думаешь?
— Что?- сказала Беатриса.
— Угадай, сколько продержится род человеческий?- сказал
Румфорд.
Из-за стиснутых зубов Беатрисы прорвался вибрирующий,
пронзительный, непрерывный звук такой высоты, что человеческое
ухо его почти не воспринимало. Этот стон звучал жутко,
угрожающе, как свист стабилизаторов падающей бомбы.
И грянул взрыв. Беагриса опрокинула кресло, бросилась на
скелет и швырнула его в угол, так что кости загремели: Она смела
все начисто со стеллажей Музея Скипа, разбивая экспонаты о
стены, дробя их об пол.
Румфорд был ошеломлен.
— Боже правый,- сказал он.- Что с тобой стряслось?
— Ах, ты разве не знаешь?- истерически выкрикнула Беатриса.-
Тебе надо объяснять? Можешь читать мои мысли!
Румфорд прижал ладони к вискам, широко раскрыл глаза.
— Помехи и шум — больше ничего не слышу,- сказал он.
— А чему же там еще быть, кроме шума!- сказала Беатриса.-
Меня вот-вот выкинут на улицу, мне хлеба купить будет не на что
— а мой муж посмеивается и предлагает поиграть в угадайку!
— Да ведь это не _просто_ игра!- сказал Румфорд.- Я
спрашивал, сколько протянет род человеческий. Мне казалось, что
это позволит тебе взглянуть на собственные дела как бы в
перспективе.
Курт Воннегут, «Сирены Титана»
17. Если часы на сервере и клиенте рассинхронизированы, они по крайней мере всегда рассинхронизированы на постоянное количество секунд.
1) 15 декабря — 15 января — это тоже месяц (не календарный, а продолжительность времени)
2) декабрь в Лос-Анжелесе заканчивается в следующем году по UTC
3) наверняка, еще что-то есть
Миф: Когда вы видите в сетевом протоколе поле «время» — это действительно время в какой-то точке пространства.
Реальность: В сетевом протоколе любого уровня, который расчитан не на специализированное применение в области физики, время — это просто абстрактный идентификатор запроса для специализированных целей для стороны, генерирующей соответствующее значение (для отсчёта таймаутов, помещения запроса в тот или иной диапазон транзакций и т.п.). Соответственно, если вы разрабатываете такой протокол для OTP, имеет смысл задизайнить поле «время» для «времени» по субъективным ощущением удалённой стороны.
0) время — непостоянная штука. Нет надежды на его дискретность, нет надежды на его однонаправленность.
Бывают смешные баги, когда дата модификации какого-нибудь файла установлена до 1970-го года (а вы, например, по датам проверяете файл на обновление или ещё что-то). Мой товарищ на такую напоролся однажды.
Но если при проектировании, например, той же десктопной ОС мы не учтем, например, високосные секунды, мир перевернется?
А насчет того, что минимальной единицей времени является миллисекунда (наносекунда и т.п) — если уж на то пошло, в принципе не сушествует минимального числа в множестве (0, 1] и мы с этим уже ничего не поделаем.
Видимо из-за вечерней усталости сначала воспринял список как «вот правила, которых стоит придерживаться», дочитал до 6го пункта и думаю «да ну, что за бред, ей богу», полез в комментарии, ожидая увидеть опровержение, но нет, все тихо-мирно. Хм, окей, читаю дальше, но что-то не тоооо… На 13 пункте все же заподозрил неладное и перечитал заголовок списка — «Все эти предположения ошибочны», фух, аж отлегло от сердца, а то уже батхёрт начался. Лучше утром почитаю =)
наводит на мысли что такое количество сложностей должно было породить какую-то библиотеку? или утилиту? или сервис? который большинство из них решает в стандартном виде… разве нет ничего такого? или слишком разные задачи, среды и проблемы
Кому-то нужно, что бы в XVI веке был пропуск в 13 дней, кому-то — что бы в XXм, а кому-то вообще нужно, что бы грегорианский был «экстраполирован» в прошлое. Вот уже появилось несколько десятков (по числу разных дат принятия грегорианского календаря) различий в решении — только по одному ключевому вопросу.
* Документы никогда не будут вводиться задним числом
* Ну хорошо, будут, но тогда при отборе документов по дате они должны выдаваться наравне с документами, оформленными правильной датой
* Если на форме запрашивается только дата, то будет присваиваться время 00:00
* При смене часового пояса такие даты будут отображаться верно
9. Ладно, это неправда. Но, по крайней мере, часовой пояс не будет меняться.
А если на другой планете?
Заблуждения программистов относительно времени