Комментарии 57
2) Ее уже переводили на Хабре минимум два раза: раз, два.
Upd. Второе — это перевод более поздней и расширенной версии.
Upd2. При более внимательном прочтении — не перевод.
habr.com/ru/post/146109
habr.com/ru/post/313274
habr.com/ru/post/452584
Заблуждения об именах:
habr.com/ru/post/431866
habr.com/ru/post/146901
Адреса:
habr.com/ru/company/hflabs/blog/260601
что там будут обязательно три числа: год, месяц и день и не будет букв.
простите, это как ?
При этом, если установлен только год, то днём рождения считают 1 июля, если первая половина года, то 1 апреля, вторая половина года — 1 октября, если установлен месяц, то 15 число этого месяца.
Ну и, теоретически, может быть указана неверная дата, например 31 июня.
Поправка: не днём рождения, а датой наступления полного количества скольких-то лет в юридических целях типа возможности избирать или быть избранным
Да, там именно «XX» — буквами латинского алфавита. Не РФный.
С учетом, сколько сейчас всего завязано на жесткое соответствие данных с данными из паспорта…
«примеры замены даты рождения являются одинаковыми во всём мире». Встречал год рождения 9999, возникал при оцифровке архива
Я выполнил эту несложную рекомендацию, на моей сети ничего не упало.
При своей загрузке Linux берёт текущее аппаратное время,
откуда берется текущее аппаратное время и почему его дальше нельзя использовать блог компании Mail.ru Group не уточняет.
И что различие времен на клиенте и сервере связано как раз с различием этого самого аппаратного времени т.е. часов CMOS, если не стоит периодическая синхронизация, не говорится.
Так же граждане из Mail.ru Group не упоминают о наличии милли- и микросекунд, с которыми тоже не все так однозначно и что помимо персональных и не очень персональных компьютеров есть микропроцессоры, в которых может быть несколько таймеров и там со временем тоже случаются приключения.
В месяце может быть 28, 29, 30 или 31 день.
А с этим что не так?
1918 год. В России после 31-го января наступило 14-е февраля.
1892 год. Западное Самоа меняет часовой пояс и празднует 4 июля дважды. В их 1892 году было 367 дней, из них 32 — в июле.
Если я всё правильно помню, то у китайцев например бывает 13-й месяц. И это тоже иногда нужно учитывать.
Такое тоже бывает. Но тут уже сложнее на грабли наступить так как это часть ТЗ.
Переменная может вызываться из программы, которая работает в виртуальной машине. Виртуальная машина засаспенжена, а потом внезапно восстанавливает работу через неделю и сразу же синхронизирует время.
Ну, проработала она физически 3 недели из месяца — что это меняет? Если ее спросят (условно) «Что ты делал месяц назад?» ей же дату календарную определять, а не по своей фактической работе.
Это если она дату календарную записывает, а не количество тиков от старта
Это даже не неверная работа со временем, а замена реального времени каким-то левым параметром.
А причём тут количество дней в месяце? )
Но программист может не знать, что на системе не реальное время. Более того, основное заблуждение программиста, имхо, при работе со временем это то, что он (его программа) может его получить
А так — да, можно к списку в статье добавить такую проблему:
— То, что программист считает временем — не обязательно им является.
Вам же привели примеры, когда количество дней в месяце официально не было 28-31.
И к этому вдобавок ответ на запрос "какая дата была месяц назад" может вернуть неожиданный результат по множеству аппаратных и программных причин, начиная с неверной текущей даты из-за неточных RTC
Вам же привели примеры, когда количество дней в месяце официально не было 28-31.
Мы же сейчас не об этих примерах, а о влиянии простоя. С этими примерами я не спорю, хотя они тоже довольно специфические.
может вернуть неожиданный результат по множеству аппаратных и программных причин,
Может, но с количеством дней в месяце эти причины не связаны.
Так же довольно часто возникают проблемы, если в процессе работы программы поменялось время и «Время начала работы процесса» становится позже, чем «Время конца работы процесса»
Особенно этим страдают разработчики в Москве. Когда не задумываясь использует формат без TZ в API.
Когда начинаешь спрашивать «А в какой зоне у вас время в API?», то очень удивляются и… часто отвечают «Время то оно одно у всех» (С)
А еще требования
- «Не хотим что бы в АРМ отображалось время с TZ места события».
- «Хотим что бы оператору было интуитивно понятно в какой момент произошло событие»
А потом начинается… «Тут в чеке у клиента указано что он оплатил в 16:30», а у меня время в АРМ 09:30. Незя так!!! (а ничо, что клиен платил не Москве, а оператор в Москве пялится в экран)
Хорошо… незя так незя… Показываешь время в таймзоне события (без показа таймзоны ибо этот показ вызывает перегрев мозгов операторов).
«А Почему у вас время показывается 16:30, а клиент сделал операцию в 09:30 по Москве.»
После требований «давайте не будем показывать TZ, операторы не понимают что это такое», я теряю веру в человечество.
Особенно если "местное" для них по жизни синоним "по Москве"
Эм, человек, который считает, что на сервере и на клиенте время одинаковое, никогда не пробовал общаться с сервером, у которого скорость измеряется в процентах от c. Дальше там есть школьный учебник с сложной формулой перевода времени из одного frame of reference в другой.
Программистские заблуждения, что этого ещё не было на Хабре.
В арабских странах:
- Неделя начинается не в понедельник, а в воскресенье.
- Выходными считаются пятница и суббота
Из пункта 1 следует, что США — арабская страна, равно как и Израиль из второго пункта?
Не следует. Есть утверждение: Вася любит пиццу. Из этого утверждения не следует, что я Вася, так как я люблю пиццу.
А «сверху» Unix-время ограничено 19 января 2038 года, когда количество секунд с начала отсчёта достигнет 2^31, а это число системы могут посчитать отрицательным
В Linux с незапамятных времён на 64-х битных системах time_t — 64 бита. А, начиная с версии 5.6, и в 32-х битных системах, тоже.
А, начиная с версии 5.6, и в 32-х битных системах, тоже.
Это только касательно внутреннего представления и новых системных вызовов, в которые новая libc заботливо транслирует библиотечные вызовы. А вот старые бинарники, собранные со старой libc, всё ещё пользуются старыми системными вызовами, потому что их бинарный код считал и считает time_t 32-битным.
Зы: посмотрел, что там у меня в мелкопроцессорном це для time_t
typedef unsigned int time_t; /* date/time in unix secs past 1-Jan-70 */
т.е. для мелкопроцессорной железяки нет проблемы 2038 года. Зато будут у компьютерной программы на писи, которая это время читает в свое time_t, которое чтобы не заморачиваться использует #define _USE_32BIT_TIME_T
Мой любимый абзац tzdata:
В Саудовской Аравии учёт времени вёлся по-всякому, в зависимости от того, кто вы и где находитесь. В 1969 году Элаяс Антар пишет, что обычай предписывал устанавливать часы на 12:00 (т. е., полночь) на закате — что для жителей гор означало существенно разное время, в зависимости от того, на каком склоне они находятся — однако многие иностранцы свои часы устанавливали в 6 вечера, в то время как авиалинии последовательно использовали UTC+3 (кроме Дахрана, где использовался UTC+4), АРАМКО использовала UTC+3 и летнее время, а Трансаравийская Нефтяная Компания использовала правила АРАМКО в восточной части страны и авиационные правила на западе. (Американская консультационная группа по вопросам военной помощи использовала просто UTC, без сдвигов.) Антар пишет: «Местной электростанцией в то время заведовал человек по имени Хиггинс. Однажды ему это всё так надоело, что он собрал персонал и объявил закон: “С меня хватит,” — воскликнул он, — “Сейчас ровно 12 часов по времени Хиггинса. Отныне эта станция работает по времени Хиггинса.” И с тех пор, до прошлого года, она так и работала.»
Antar E. Dinner at When? Saudi Aramco World, 1969 March/April. 2-3
http://archive.aramcoworld.com/issue/196902/dinner.at.when.htm
обычай предписывал устанавливать часы на 12:00 (т. е., полночь) на закате
Так це ж византийское время. Как на Афоне
https://radiovera.ru/afon-zhit-po-vizantiyskomu-vremeni.html
Помню как завис знакомый mysql когда в России отменили переход на летнее время. В смысле, когда настал день. когда должны были перейти, но с новым законом не стали. Обновления tzdata в ОС стояли, но у мускуля свои отношения с tz
до сих пор не реализовала в Windows аналог tzinfo()
В WinAPI есть timezoneapi.h, в котором как будто бы есть нужные функции и структуры.
В одном из проектов мне нужно было считать время, я чтобы не заморачиваться, захардкодил длину года как 365.25 дней. В принципе это работало, грабли не вылезли (вроде бы).
Как то в одном проекте мы делали продажу ЖД билетов, мой коллега все реализовал и все работало ОК. Как то к нам поступила заявка, проверить один странный баг. Клиент жаловался на то, что он покупал билет на одну дату а ему продали на другую. Мой коллега так и не смог воспроизвести этот баг. Я при изучении тестовых логов, обнаружил, что время было сдвинуто на 3 часа. Как оказалось, это было смещение UTC+3. То есть, если покупать билет ночью, то есть шанс купить билет на другие сутки из-за локального расчета времени как UTC+0.
По результатам проверки бага, техподдержка написала клиенту отписку в стиле «сам балбес», стоимость билета компенсировать отказались, а историю тихо замяли. Как то так.
365.24 же по феншую
Юзер пользуется почтовой программой и через маил.ру в 13:03 МСК (10:03 по гринвичу) отправляет письмо.
Но, у него стоит неправильный часовой пояс +4, при правильном времени (13:03).
Получается, что письмо он отправил в 09:03 по гринвичу.
Сервер это все перерабатывает и получателю показывает письмо отправленное в 12:03 МСК, за час до написания. И с таким же временем кладет письмо в папку отправленные, юзер его потом не может найти («я же писал его в 13, ну никак не раньше»).
Если бы у юзера было сильно неправильное время, сервер вроде это корректирует, но не часовой пояс.
Про разницу сервера и клиента.
Несколько лет назад в России перестали переводить время зимой/летом. Мой коллега сидел на Windows XP, патча для которой не было. Чтобы видеть правильное время на экране при использовании неправильного (непропатченного) часового пояса, он просто перевел системные часы на час.
И все работало хорошо. До тех пор, пока ему не понадобилось сделать аплоад файла из браузера на AWS S3. Клиентский модуль в браузере добавляет заголовок "x-amz-date" со временем браузера. Это время не соответствует подписи, сделанной на бэкенде. В итоге S3 отвечает ошибкой.
Было очень непросто найти источник проблемы :)
При сильной разнице во времени у клиента и сервера, всегда будет ошибка валидации на https.
Сколько бы можно было избежать если бы работал Удобный Шестидневный календарь
Некоторые программистские заблуждения о времени