Открыть список
Как стать автором
Обновить

Комментарии 57

1) Здесь не указано, что это перевод (или вольный пересказ) вот этой статьи.
2) Ее уже переводили на Хабре минимум два раза: раз, два.
Upd. Второе — это перевод более поздней и расширенной версии.
Upd2. При более внимательном прочтении — не перевод.
Так в расширенной версии добавили что-то полезное? В любом случае, хорошим тоном для перевода является указывать, что это вторая версия оригинала, и.т.п.
Заблуждение о дате рождения в паспорте:
что там будут обязательно три числа: год, месяц и день и не будет букв.

простите, это как ?

Бывают варианты, когда дата рождения в паспорте указана только месяцем и годом или только годом.
При этом, если установлен только год, то днём рождения считают 1 июля, если первая половина года, то 1 апреля, вторая половина года — 1 октября, если установлен месяц, то 15 число этого месяца.
Ну и, теоретически, может быть указана неверная дата, например 31 июня.

Поправка: не днём рождения, а датой наступления полного количества скольких-то лет в юридических целях типа возможности избирать или быть избранным

Пример от балды на основе реального тикета на исправление информционной системы: XX.XX.1930
Да, там именно «XX» — буквами латинского алфавита. Не РФный.

С учетом, сколько сейчас всего завязано на жесткое соответствие данных с данными из паспорта…
Доп.заблуждение о паспорте.
«примеры замены даты рождения являются одинаковыми во всём мире». Встречал год рождения 9999, возникал при оцифровке архива
Автор ждёт комментарий? Пожалуйста: в 2012 году 30 июня 23:59:60 UTC была добавлена секунда координации. Один крупный международный вендор телеком-оборудования, зная о наличии бага в своём софте, разослал всем клиентам настоятельную рекомендацию выключить синхронизацию от внешнего источника по NTP за 12 часов до этого момента, и включить через 12 часов после полуночи 1 июля по UTC.
Я выполнил эту несложную рекомендацию, на моей сети ничего не упало.
Поэтому у программистов никогда нет времени на то, чтобы сделать все правильно, но всегда есть время на то, чтобы сделать этого больше)
При своей загрузке Linux берёт текущее аппаратное время,

откуда берется текущее аппаратное время и почему его дальше нельзя использовать блог компании Mail.ru Group не уточняет.
И что различие времен на клиенте и сервере связано как раз с различием этого самого аппаратного времени т.е. часов CMOS, если не стоит периодическая синхронизация, не говорится.

Так же граждане из Mail.ru Group не упоминают о наличии милли- и микросекунд, с которыми тоже не все так однозначно и что помимо персональных и не очень персональных компьютеров есть микропроцессоры, в которых может быть несколько таймеров и там со временем тоже случаются приключения.

В месяце может быть 28, 29, 30 или 31 день.

А с этим что не так?
1582 год. У католиков в октябре после 4-го числа сразу настало 15-е.
1918 год. В России после 31-го января наступило 14-е февраля.

1892 год. Западное Самоа меняет часовой пояс и празднует 4 июля дважды. В их 1892 году было 367 дней, из них 32 — в июле.

А в 2011 Самоа меняет пояс обратно с UTC-11 на UTC+13 и после 29-го декабря наступает сразу 31-е.
30 дней — всё норм, хоть и нетипично для Декабря (ну да, ещё 30-е «потерялось», а 31-е — «лишнее» (для месяца с 30 днями))
И в году было 364 дня.

Если я всё правильно помню, то у китайцев например бывает 13-й месяц. И это тоже иногда нужно учитывать.

Он и в российских банках раньше был без всяких там китайцев. На него в отчетности «садились» приходы, отправленные в декабре и принятые в январе. Их надо было учитывать отдельно от тех приходов, которые полностью шли в текущий год.

Такое тоже бывает. Но тут уже сложнее на грабли наступить так как это часть ТЗ.

Ответ на этот и на другие вопросы:
Переменная может вызываться из программы, которая работает в виртуальной машине. Виртуальная машина засаспенжена, а потом внезапно восстанавливает работу через неделю и сразу же синхронизирует время.
Вот этого не понял.
Ну, проработала она физически 3 недели из месяца — что это меняет? Если ее спросят (условно) «Что ты делал месяц назад?» ей же дату календарную определять, а не по своей фактической работе.

Это если она дату календарную записывает, а не количество тиков от старта

Какое отношение все это имеет к количеству дней в месяце?
Это даже не неверная работа со временем, а замена реального времени каким-то левым параметром.

А причём тут количество дней в месяце? )


Но программист может не знать, что на системе не реальное время. Более того, основное заблуждение программиста, имхо, при работе со временем это то, что он (его программа) может его получить

Это понятно, но он просто получит неправильное количество секунд (или чего-то еще), по ним вычислит неправильное количество минут-часов-дней-месяцев и т.д. Это не имеет отношения к вопросу про количество дней в месяце.

А так — да, можно к списку в статье добавить такую проблему:
— То, что программист считает временем — не обязательно им является.

Вам же привели примеры, когда количество дней в месяце официально не было 28-31.


И к этому вдобавок ответ на запрос "какая дата была месяц назад" может вернуть неожиданный результат по множеству аппаратных и программных причин, начиная с неверной текущей даты из-за неточных RTC

«Месяц назад» и «месяц вперёд» — это вообще не строго определённые понятия. Месяц назад от 31 марта — это какое число? Предположим, 28 февраля. Тогда месяц вперёд от 28 февраля — это 28 или 31 марта?
Не правильные примеры) С последними днями месяца ещё норм, тут лучше 29 марта и 26 февраля)
Вам же привели примеры, когда количество дней в месяце официально не было 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-битным.

не обязательно старые. Есть некоторое количество линуксов, рт-осов или вообще безоперационных систем на 32битных мелкопроцесорах, там тоже sizeof(time_t) = 4

Зы: посмотрел, что там у меня в мелкопроцессорном це для 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

Помню как завис знакомый mysql когда в России отменили переход на летнее время. В смысле, когда настал день. когда должны были перейти, но с новым законом не стали. Обновления tzdata в ОС стояли, но у мускуля свои отношения с tz

А еще в виртуальной машине время может отставать :-E
до сих пор не реализовала в 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.

А сколько бы проблем добавилось по поддержке еще одного календаря и конвертации даты между ними… Если к власти придут программисты из 1с, они наверное именно это и сделают.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
team.mail.ru
Численность
5 001–10 000 человек
Дата регистрации
Представитель
Павел Круглов

Блог на Хабре