Comments 57
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 июня.
«примеры замены даты рождения являются одинаковыми во всём мире». Встречал год рождения 9999, возникал при оцифровке архива
Я выполнил эту несложную рекомендацию, на моей сети ничего не упало.
При своей загрузке Linux берёт текущее аппаратное время,
откуда берется текущее аппаратное время и почему его дальше нельзя использовать блог компании Mail.ru Group не уточняет.
И что различие времен на клиенте и сервере связано как раз с различием этого самого аппаратного времени т.е. часов CMOS, если не стоит периодическая синхронизация, не говорится.
Так же граждане из Mail.ru Group не упоминают о наличии милли- и микросекунд, с которыми тоже не все так однозначно и что помимо персональных и не очень персональных компьютеров есть микропроцессоры, в которых может быть несколько таймеров и там со временем тоже случаются приключения.
В месяце может быть 28, 29, 30 или 31 день.
А с этим что не так?
1918 год. В России после 31-го января наступило 14-е февраля.
Переменная может вызываться из программы, которая работает в виртуальной машине. Виртуальная машина засаспенжена, а потом внезапно восстанавливает работу через неделю и сразу же синхронизирует время.
Ну, проработала она физически 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, в котором как будто бы есть нужные функции и структуры.
Юзер пользуется почтовой программой и через маил.ру в 13:03 МСК (10:03 по гринвичу) отправляет письмо.
Но, у него стоит неправильный часовой пояс +4, при правильном времени (13:03).
Получается, что письмо он отправил в 09:03 по гринвичу.
Сервер это все перерабатывает и получателю показывает письмо отправленное в 12:03 МСК, за час до написания. И с таким же временем кладет письмо в папку отправленные, юзер его потом не может найти («я же писал его в 13, ну никак не раньше»).
Если бы у юзера было сильно неправильное время, сервер вроде это корректирует, но не часовой пояс.
Про разницу сервера и клиента.
Несколько лет назад в России перестали переводить время зимой/летом. Мой коллега сидел на Windows XP, патча для которой не было. Чтобы видеть правильное время на экране при использовании неправильного (непропатченного) часового пояса, он просто перевел системные часы на час.
И все работало хорошо. До тех пор, пока ему не понадобилось сделать аплоад файла из браузера на AWS S3. Клиентский модуль в браузере добавляет заголовок "x-amz-date" со временем браузера. Это время не соответствует подписи, сделанной на бэкенде. В итоге S3 отвечает ошибкой.
Было очень непросто найти источник проблемы :)
Сколько бы можно было избежать если бы работал Удобный Шестидневный календарь
Некоторые программистские заблуждения о времени