«Never say never» или Работаем с таймзонами правильно

Спасибо за ссылки! Отличное дополнение к статье :-)

Я не пытался составить полный перечень проблем, просто хотел обратить внимание, что бездумное следование чьим-то советам может привести к страданиям. Хотел на примерах показать некоторые из подводных камней.

«Never say never» или Работаем с таймзонами правильно

Ничего из того, что вы написали, не противоречит моей статье :-)

Вот моя основная мысль (позволю себе процитировать её ещё раз):

Вывод можно сделать простой и совершенно банальный: никогда не слушайте категоричных утверждений, рекомендующих вам никогда не делать тех или иных вещей. Всегда продумывайте и прорабатывайте все возможные варианты, особо внимательно прорабатывайте архитектуру проекта, пишите качественные тесты и поддерживайте их в актуальном состоянии.

Случай с таблеткой настолько уникален и вырожден, что я не могу придумать ни одного подходящего варианта из реальной жизни. И я не слышал вообще ни одной жалобы от пользователя относительно того, что все события в календаре остались на своих местах (по локальному времени), хотя полгода назад он задавал их в UTC. Понимаете, к чему я клоню? Подавляющее большинство пользователей ожидает, что если они поставили событие на 10 утра, оно произойдёт в 10 утра, даже если поменяется часовой пояс.

Мы не можем оправдываться перед пользователями тем, что они должны были знать про закон о переводе часов, должны были зайти в наш календарь и сами должны были передвинуть все события после 26 октября на час вперёд. Если мы скажем им, что мы не могли решать за них, что важно, а что нет, это будет выглядеть совершенно глупо, и в таком случае я буду первый, кого уволят с работы и я тоже буду «бывшим разработчиком календаря».

Кстати, из-за странного бага в связке iCal у нас в некоторых случаях некоторые события сдвинулись назад (iCal переписал их поверх старых с той датой, которая, как он думал, была правильная). И вот тут-то каждый пользователь счёл своим долгом пожаловаться нам, что мы — уроды, и не можем сделать нормальный календарь, что нам следовало бы следить за законами о переводах часов и что нас всех следует уволить.

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

В статье вы пытаетесь «зашить» бизнес-логику в формат хранения данных.

Нет.

Приведение времени события к UTC или хранение тайм-зоны — достаточно.

Да нет же =) Ну прочитайте же статью, я ведь написал там про то, что произойдёт, если мы будем хранить время в UTC, и почему этого недостаточно :-)

С уважением к коллеге, Владимир.

«Never say never» или Работаем с таймзонами правильно

Timestamp — это то же время в UTC, просто для удобства работы с ним представленное не в виде объекта, а в виде числа. «Timestamp with timezone» — вообще другое. Попробуйте перевести время «2014-10-26 01:30:00» в таймзоне «Europe/Moscow» в UNIX-timestamp?

Мне кажется, вы не читали статью, простите за грубость.

«Never say never» или Работаем с таймзонами правильно

Насколько я вообще знаю, сложная работа со временем в JS просто невозможна нативными средствами. Например, нельзя однозначно определить таймзону пользователя, можно только получить общую информацию — смещение относительно UTC, включен ли переход на летнее время и т.д. И по этой информации попытаться угадать часовой пояс (что будет просто пальцем в небо). Учитывая огромное количество компьютеров со старыми версиями ОС (пресловутый XP), а так же компьютеров, пользователи которых тупо не ставят обновления (в которых приходят новые настройки часовых поясов), и при проблемах с часами просто переводят их руками, это грозит катастрофой.

Плюс часы могут быть не синхронизированы у пользователя, например, да вообще много разных проблем проявляется в реальных больших проектах где нужна особо аккуратная работа со временем (вроде того же календаря). Поэтому время с клиента (браузера) можно передавать только в UTC (если мы пользуемся нативными способами работы с датой в JS). И то будет возникать куча проблем.

Я могу ошибаться, я не так хорош в JS, как в других вещах, если я не прав, буду рад услышать замечания :-)

«Never say never» или Работаем с таймзонами правильно

Вот такой подход мне понятен :-) Я, кстати, в теме всей этой внутренней кухни разработки ИС для больших компаний (так получилось), и прекрасно понимаю, о чём речь. Всему есть своя цена и всегда есть место компромиссам и понятиям целесообразности.

«Never say never» или Работаем с таймзонами правильно

Да, ссылку на это шикарнейшее видео я давал в своём переводе, к которой аппелирует данная статья. Вообще, конечно, про работу со временем можно говорить бесконечно. Столько всего «прекрасного» придумывают люди, чтобы страдать! :-)

«Never say never» или Работаем с таймзонами правильно

Это произойдёт только если на сервере время не будет переведено. А если будет — то он получит уведомление как раз в 9 утра.

Нет. Если интересно разобраться, почему так, пожалуйста, прочитайте ещё раз соответствующий фрагмент статьи, я всё подробно описал :-)

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

«Never say never» или Работаем с таймзонами правильно

Совершенно верно, везде есть нюансы, и, например, мы не можем совершенно однозначно и точно перевести время 1:30 ночи в Москве 26 октября 2014 года в UTC. Боль и унижение :-) Однако с этим можно что-то придумать, всё зависит от ситуации. Как я писал в статье:

никогда не слушайте категоричных утверждений, рекомендующих вам никогда не делать тех или иных вещей

:-)

«Never say never» или Работаем с таймзонами правильно

Точно! Не так прочитал комментарий — не там расставил акценты :)

«Never say never» или Работаем с таймзонами правильно

Прошу меня извинить, но мне кажется, что вы невнимательно прочитали статью.

И как теперь быть с заявкой пользователя из Читы, который открыл её 1 октября, а решили её 30 октября?

Тут просто отвечу цитатой из своего текста:

Если вам нужно хранить время только что произошедшего события, текущее время, по факту определённого действия, храните его в UTC. Это могут быть записи в логах, время регистрации пользователя, совершения заказа или отправки письма.

Кроме того, даже если вы будете хранить локальное время пользователя, никаких проблем не возникнет. Вообще никаких. При условии, что вы пользуетесь правильными инструментами. Поясню чуть подробнее, что я имею в виду. Есть два варианта работы с таймзоной пользователя: правильный и неправильный.

Неправильный — это когда мы узнали, что «с 26 октября 2014 года смещение для Москвы стало UTC+3» и для всех дат в таймзоне Europe/Moscow применяем это смещение. В прошлом, в будущем, — неважно. Это категорически неправильно, однако многие продукты, и достаточно серьёзные продукты, так делают, максимум, что они могут учитывать — DST.

Правильный — это когда у нас есть база данных изменения часовых поясов (tzdata) и мы используем её. Так, согласно этой базе, до 26 октября 2014 года смещение относительно UTC было 4 часа, плюс действовал DST, а после 26 октября — три часа, без DST. И таких вот записей в базе может быть много. Но мы можем практически для любой даты получить смещение и преобразовать UTC в локальное время. И наоборот.

Не говоря о такой мякотке, как построение отчетов в business objects, который не умеет в unixtime.

Простите, но вот это «не умеет» — это смешно. Если я пользователям календаря скажу «вы знаете, мы пользуемся инструментом, который не умеет работать с часовыми поясами» — они плюнут на нас и уйдут к конкурентам.

Или вот ещё глупый пример: если при запуске спутника в космос ракета на старте упадёт, и разработчик ракеты скажет «вы знаете, у нас такая мякотка, наш софт не умеет работать с часовыми поясами и поэтому в итоге всё рассчиталось неправильно», мне кажется, его никто не поймёт. А может, даже накажут.

Если для вас работа с датами некритична, и ваши пользователи готовы мириться с кривостью и несовершенством тех инструментов, которые вы используете, и для них ошибка в плюс-минус один час приемлима, то ради Бога, никаких проблем, даже думать про таймзоны не нужно — все и так счастливы и довольны. Если же ваша работа категорически зависит от правильной работы дат, то нужно просто менять инструменты (или писать свои, хорошие).

Ну и не забывайте страдать, конечно :-)

«Never say never» или Работаем с таймзонами правильно

Я рассматриваю случай, когда пользователь изначально задал время в своём часовом поясе. Время в UTC нужно только для того, чтобы облегчить выборку по базе. В случае изменения конфигурации часового пояса, локальное время пользователя останется неизменным (он хотел получить уведомление в 10:00 по Москве, например), но время в UTC для этого локального времени изменится. Поэтому нам нужно обновить его.

«Never say never» или Работаем с таймзонами правильно

Согласен, postgresql вообще просто сказка после mysql :-)

«Never say never» или Работаем с таймзонами правильно

Опа опа, я ошибся: www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES
Посыпаю голову пеплом.

«Never say never» или Работаем с таймзонами правильно

Мы у себя как раз используем postgresql. Как раз в том-то и заключается проблема, что таймзоны в постгресе — ни разу не таймзоны, а тупо смещение относительно UTC, и толку от них — ну очень мало. Все описанные в статье проблемы остаются как есть :)

«Never say never» или Работаем с таймзонами правильно

Не хочу показаться занудой, но, если быть чуть более точным, то геоид, а не эллипсоид.

«Never say never» или Работаем с таймзонами правильно

Или вот ещё замечательный пример про timestamp:

>>> import datetime
>>> datetime.datetime.fromtimestamp(0)
datetime.datetime(1970, 1, 1, 3, 0)

«Never say never» или Работаем с таймзонами правильно

Если вы не знаете, в какой таймзоне хранится время у вас в базе, то у меня для вас плохие новости :)

«Never say never» или Работаем с таймзонами правильно

Так и есть. UNIX timestamp — то же самое, что UTC: ru.wikipedia.org/wiki/UNIX-время

Время UNIX согласуется с UTC — в частности, при объявлении високосных секунд UTC соответствующие номера секунд повторяются, то есть високосные секунды не учитываются.

«Eppur si muove!»* или Работаем с таймзонами в Python

Arrow — всего лишь инструмент. Красивый, элегантный, да, и все, кто в теме, давно уже его используют где нужно.

Но любой инструмент важно применять по назначению. Если вы будете красивым и элегантным микроскопом копать яму, то… Ну удачи, что :)

«Eppur si muove!»* или Работаем с таймзонами в Python

Это ещё цветочки, это уже в прошлом и, слава Богу, не используется. Вечером опубликую свою статью на эту тему, которую я написал, чтобы на примерах из нашей жизни показать, что с таймзонами всё ещё хуже, чем кажется.