Комментарии 103
Может быть мне кажется все слишком просто, но почему не хранить в базе все в unixtime? а отображать в интерфейсе и записывать в базу с учетом временной зоны пользователя(только предупреждать его об этом, если он сам не выбрал временную зону). Да, придется так же страдать из-за рандомных законопроектов, но от них никуда не деться, как ни храни.
Unix time чем-то отличается от UTC?
Я к тому, что с моей колокольни, Unix time — это способ записать время в UTC одним числом, не более.
Я к тому, что с моей колокольни, Unix time — это способ записать время в UTC одним числом, не более.
Так и есть. UNIX timestamp — то же самое, что UTC: ru.wikipedia.org/wiki/UNIX-время
Время UNIX согласуется с UTC — в частности, при объявлении високосных секунд UTC соответствующие номера секунд повторяются, то есть високосные секунды не учитываются.
Формой записи, если в базе есть запись «2014-12-15 15:00:00», это еще не значит что она в UTC, вариантов ошибиться всегда множество.
Ну вот у нас всё время в unixtime.
И как теперь быть с заявкой пользователя из Читы, который открыл её 1 октября, а решили её 30 октября? Как вывести время открытия и решения заявки?
Не говоря о такой мякотке, как построение отчетов в business objects, который не умеет в unixtime. И если ты хочешь в нем сделать выборку по датам, то придется unixtime из каждой строки оракловой базы переводить в Date и сравнивать со значением Date, которое пришло из BO. Миллион записей в таблице? Ну значит миллион преобразований.
И как теперь быть с заявкой пользователя из Читы, который открыл её 1 октября, а решили её 30 октября? Как вывести время открытия и решения заявки?
Не говоря о такой мякотке, как построение отчетов в business objects, который не умеет в unixtime. И если ты хочешь в нем сделать выборку по датам, то придется unixtime из каждой строки оракловой базы переводить в Date и сравнивать со значением Date, которое пришло из BO. Миллион записей в таблице? Ну значит миллион преобразований.
Прошу меня извинить, но мне кажется, что вы невнимательно прочитали статью.
Тут просто отвечу цитатой из своего текста:
Кроме того, даже если вы будете хранить локальное время пользователя, никаких проблем не возникнет. Вообще никаких. При условии, что вы пользуетесь правильными инструментами. Поясню чуть подробнее, что я имею в виду. Есть два варианта работы с таймзоной пользователя: правильный и неправильный.
Неправильный — это когда мы узнали, что «с 26 октября 2014 года смещение для Москвы стало UTC+3» и для всех дат в таймзоне Europe/Moscow применяем это смещение. В прошлом, в будущем, — неважно. Это категорически неправильно, однако многие продукты, и достаточно серьёзные продукты, так делают, максимум, что они могут учитывать — DST.
Правильный — это когда у нас есть база данных изменения часовых поясов (tzdata) и мы используем её. Так, согласно этой базе, до 26 октября 2014 года смещение относительно UTC было 4 часа, плюс действовал DST, а после 26 октября — три часа, без DST. И таких вот записей в базе может быть много. Но мы можем практически для любой даты получить смещение и преобразовать UTC в локальное время. И наоборот.
Простите, но вот это «не умеет» — это смешно. Если я пользователям календаря скажу «вы знаете, мы пользуемся инструментом, который не умеет работать с часовыми поясами» — они плюнут на нас и уйдут к конкурентам.
Или вот ещё глупый пример: если при запуске спутника в космос ракета на старте упадёт, и разработчик ракеты скажет «вы знаете, у нас такая мякотка, наш софт не умеет работать с часовыми поясами и поэтому в итоге всё рассчиталось неправильно», мне кажется, его никто не поймёт. А может, даже накажут.
Если для вас работа с датами некритична, и ваши пользователи готовы мириться с кривостью и несовершенством тех инструментов, которые вы используете, и для них ошибка в плюс-минус один час приемлима, то ради Бога, никаких проблем, даже думать про таймзоны не нужно — все и так счастливы и довольны. Если же ваша работа категорически зависит от правильной работы дат, то нужно просто менять инструменты (или писать свои, хорошие).
Ну и не забывайте страдать, конечно :-)
И как теперь быть с заявкой пользователя из Читы, который открыл её 1 октября, а решили её 30 октября?
Тут просто отвечу цитатой из своего текста:
Если вам нужно хранить время только что произошедшего события, текущее время, по факту определённого действия, храните его в UTC. Это могут быть записи в логах, время регистрации пользователя, совершения заказа или отправки письма.
Кроме того, даже если вы будете хранить локальное время пользователя, никаких проблем не возникнет. Вообще никаких. При условии, что вы пользуетесь правильными инструментами. Поясню чуть подробнее, что я имею в виду. Есть два варианта работы с таймзоной пользователя: правильный и неправильный.
Неправильный — это когда мы узнали, что «с 26 октября 2014 года смещение для Москвы стало UTC+3» и для всех дат в таймзоне Europe/Moscow применяем это смещение. В прошлом, в будущем, — неважно. Это категорически неправильно, однако многие продукты, и достаточно серьёзные продукты, так делают, максимум, что они могут учитывать — DST.
Правильный — это когда у нас есть база данных изменения часовых поясов (tzdata) и мы используем её. Так, согласно этой базе, до 26 октября 2014 года смещение относительно UTC было 4 часа, плюс действовал DST, а после 26 октября — три часа, без DST. И таких вот записей в базе может быть много. Но мы можем практически для любой даты получить смещение и преобразовать UTC в локальное время. И наоборот.
Не говоря о такой мякотке, как построение отчетов в business objects, который не умеет в unixtime.
Простите, но вот это «не умеет» — это смешно. Если я пользователям календаря скажу «вы знаете, мы пользуемся инструментом, который не умеет работать с часовыми поясами» — они плюнут на нас и уйдут к конкурентам.
Или вот ещё глупый пример: если при запуске спутника в космос ракета на старте упадёт, и разработчик ракеты скажет «вы знаете, у нас такая мякотка, наш софт не умеет работать с часовыми поясами и поэтому в итоге всё рассчиталось неправильно», мне кажется, его никто не поймёт. А может, даже накажут.
Если для вас работа с датами некритична, и ваши пользователи готовы мириться с кривостью и несовершенством тех инструментов, которые вы используете, и для них ошибка в плюс-минус один час приемлима, то ради Бога, никаких проблем, даже думать про таймзоны не нужно — все и так счастливы и довольны. Если же ваша работа категорически зависит от правильной работы дат, то нужно просто менять инструменты (или писать свои, хорошие).
Ну и не забывайте страдать, конечно :-)
Эм… маленькая деталь. Вы — разработчик бесплатного сервиса. Пользователь пришел, пользователь ушел. Надо бороться за качества продукта, менять его, добавлять новые фичи.
Я — админ купленной для большой компании ИС. И я не могу, когда захочу, потратить N часов и сделать вменяемую поддержку tzdata, например. потому что я не разаботчик этой системы, а настройками такого не добиться.
Как потенциальный пользователь календаря мэйл.ру я очень рад слышать такую позицию. Как фактический пользователь BO если я скажу «эй, чуваки, у вас тут unixtime`ом и поддержкой наших классных часовых поясов не пахнет в той древней версии, что у нас есть» — угадайте, куда я пойду?
Да пока пользователи не наседают, я и не страдаю. А среди них пока только 1 заметил :)
Я — админ купленной для большой компании ИС. И я не могу, когда захочу, потратить N часов и сделать вменяемую поддержку tzdata, например. потому что я не разаботчик этой системы, а настройками такого не добиться.
Простите, но вот это «не умеет» — это смешно. Если я пользователям календаря скажу «вы знаете, мы пользуемся инструментом, который не умеет работать с часовыми поясами» — они плюнут на нас и уйдут к конкурентам.
Как потенциальный пользователь календаря мэйл.ру я очень рад слышать такую позицию. Как фактический пользователь BO если я скажу «эй, чуваки, у вас тут unixtime`ом и поддержкой наших классных часовых поясов не пахнет в той древней версии, что у нас есть» — угадайте, куда я пойду?
Ну и не забывайте страдать, конечно :-)
Да пока пользователи не наседают, я и не страдаю. А среди них пока только 1 заметил :)
бессмысленный комментарий, простите)
Все как один. Настал черед.
Ударим дружно, памятуя
О смерти господа. Вперед!
Господь наш схвачен был врагами.
Он злые муки претерпел
И принял смерть… Победа с нами!
Вперед, кто доблестен и смел!
не забывайте страдать :-)Вперед! За благодать святую —
Все как один. Настал черед.
Ударим дружно, памятуя
О смерти господа. Вперед!
Господь наш схвачен был врагами.
Он злые муки претерпел
И принял смерть… Победа с нами!
Вперед, кто доблестен и смел!
«Не забывайте страдать» записал себе в афоризмы.
Даже целая парадигма есть — «Разработка через страдание» (Suffering-oriented programming)
Хранить гео-координаты — очень умно. Лишь бы какому-нибудь злому гению не пришло в голову «поправить» начало координат…
Тсс, в госдуме ещё не слышали про широту и долготу. Предлагаю им об этом и не говорить.
Не хочу вас расстраивать, но помимо WGS 84, с которым работает GPS и большинство веб-сервисов картографии, существуют и другие. Например Пулково-1942 (применялся в СССР и России), а сейчас ПЗ-90 — угадайте кто ее ввел. Кроме того, у многих стран тоже есть своя система координат, «наиболее лучшим образом» описывающая ее территорию. Хотя казалось бы, эллипсоид он и есть эллипсоид…
Не хочу показаться занудой, но, если быть чуть более точным, то геоид, а не эллипсоид.
В том то и дело, что геоид. А эллипсоид это так, аппроксимация.
WGS 84 даёт самую точную аппроксимацию по миру в целом. А вот в отдельных странах может быть вариант и получше… ПЗ-90, например
WGS 84 даёт самую точную аппроксимацию по миру в целом. А вот в отдельных странах может быть вариант и получше… ПЗ-90, например
Они вот тут решили, что 31 декабря называть нерабочим днем — это «бесперспективно», что, на фоне иных принимаемых ими законов, и правда кажется неделовым и неполезным законом.
Так что — тише, а то вдруг кто-то из их помощников погуглит слова «депутат» и «госдума», чтобы опнять настроения в Сети, и наткнется на ваш ответ… )
Так что — тише, а то вдруг кто-то из их помощников погуглит слова «депутат» и «госдума», чтобы опнять настроения в Сети, и наткнется на ваш ответ… )
Мечтаю дожить до того дня, когда к власти придут программисты.
Да это ладно. Вот если начнут города двигать…
Ну или забыть наконец про mysql и юзать postgresql, где работать с датами можно нативно, включая таймзоны. Есть нативная функция timezone('GMT+3', ts). В добавок: не нужно хранить таймзону в отдельном поле — есть спец тип: timestamp with timezone для этого. И конвертирование вдругие таймзоны еще проще. Единственное что нужно всегда помнить: функция timezone по-разному работает для типов ts with tz и для ts without tz, тут можно немного накосячить если не понимать разницу.
Проблемы появляются только когда происходит незапланированный во всем мире переход в другую зону как в этом году с Россией. Тут начинаются косяки с зонами типа «Europe/Moscow» т.к. сдвиг для них не обновился. Тут уж ничего не поделаешь — нужно ручками в БД править. Если не ошибаюсь, то от рута в postgresql можно исправить сдвиг прямо во встроенной в postgresql таблице таймзон (не помню уже как она называется, но она точно есть в виде обычной таблицы бд + расположена она не в схеме public)
Проблемы появляются только когда происходит незапланированный во всем мире переход в другую зону как в этом году с Россией. Тут начинаются косяки с зонами типа «Europe/Moscow» т.к. сдвиг для них не обновился. Тут уж ничего не поделаешь — нужно ручками в БД править. Если не ошибаюсь, то от рута в postgresql можно исправить сдвиг прямо во встроенной в postgresql таблице таймзон (не помню уже как она называется, но она точно есть в виде обычной таблицы бд + расположена она не в схеме public)
Мы у себя как раз используем postgresql. Как раз в том-то и заключается проблема, что таймзоны в постгресе — ни разу не таймзоны, а тупо смещение относительно UTC, и толку от них — ну очень мало. Все описанные в статье проблемы остаются как есть :)
Опа опа, я ошибся: www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES
Посыпаю голову пеплом.
Посыпаю голову пеплом.
Я пока не заметил в postgresql косяков с таймзонами, так что можно вполне уверенно их использовать. Нативное почти всегда лучше. Тем более в постгресе куча плюшек для работы со временем =)
Согласен, postgresql вообще просто сказка после mysql :-)
Ура! +1 к армии перешедших на постгрес! =) Я после постргеса мускл использую только для небольших сайтов, где база по сути нужна только для хранения небольшого количества инфы, не больше. + страхую эту систему 80-100% кешированием в память ибо ну его тот мускл с его приколами к чертям =). Иногда даже использую sqlite + cache вместо mysql, если совсем уж сайтик прост
К сожалению, PostgreSQL не хранит информацию о часовых поясах. Когда вы делаете
Проверяется это легко:
INSERT '2014-11-10 12:13:14 Europe/Moscow' INTO table; Постгрес конвертирует эту дату в UTC согласно часовому поясу (-3 часа для данной даты, сентябрьскую сдвинет на -4), а потом информацию о часовом поясе просто выкидывает. Увы. Надо хранить в колонке рядом всё же.Проверяется это легко:
CREATE TABLE tz (
"timestamp" timestamp with time zone
)
INSERT INTO tz ("timestamp") VALUES
('2014-10-10 12:13:14 Europe/Moscow'),
('2014-11-10 12:13:14 Europe/Moscow'),
('2014-10-10 12:13:14 Asia/Yakutsk'),
('2014-11-10 12:13:14 Asia/Yakutsk'),
('2014-10-10 12:13:14 Asia/Tokyo'),
('2014-11-10 12:13:14 Asia/Tokyo');
SELECT * FROM tz;
timestamp
------------------------
2014-10-10 12:13:14+04
2014-11-10 12:13:14+03
2014-10-10 06:13:14+04
2014-11-10 06:13:14+03
2014-10-10 07:13:14+04
2014-11-10 06:13:14+03
test=# SELECT "timestamp" AT TIME ZONE 'UTC' FROM tz;
timezone
---------------------
2014-10-10 08:13:14
2014-11-10 09:13:14
2014-10-10 02:13:14
2014-11-10 03:13:14
2014-10-10 03:13:14
2014-11-10 03:13:14
test=# SELECT "timestamp" AT TIME ZONE 'Asia/Yakutsk' FROM tz;
timezone
---------------------
2014-10-10 18:13:14
2014-11-10 18:13:14
2014-10-10 12:13:14
2014-11-10 12:13:14
2014-10-10 13:13:14
2014-11-10 12:13:14
test=# SELECT "timestamp" AT TIME ZONE 'Asia/Tokyo' FROM tz;
timezone
---------------------
2014-10-10 17:13:14
2014-11-10 18:13:14
2014-10-10 11:13:14
2014-11-10 12:13:14
2014-10-10 12:13:14
2014-11-10 12:13:14
Хм, а что там написано, опровергающее Ваши слова?) Да, Постгрес понимает названия и аббревиатуры таймзон. Но тип timestamp with time zone всё равно хранит только UTC-время + смещение, а не название таймзоны. Хотя его, конечно, можно рядом положить, как строку…
Я, правда, сам на своём сайте использую именно постгресовый timestamptz, но у меня нет дат в будущем, так что пока более-менее всё нормально.
Спасибо, кстати, за статью. Хранить город (координаты) пользователя — это классная идея. Но поделитесь, как вы потом переводите эту точку в таймзону? Где-то есть актуальные границы таймзон? Я знаю только efele.net/maps/tz/, но там последнее обновление было год назад…
Я, правда, сам на своём сайте использую именно постгресовый timestamptz, но у меня нет дат в будущем, так что пока более-менее всё нормально.
Спасибо, кстати, за статью. Хранить город (координаты) пользователя — это классная идея. Но поделитесь, как вы потом переводите эту точку в таймзону? Где-то есть актуальные границы таймзон? Я знаю только efele.net/maps/tz/, но там последнее обновление было год назад…
Да, всё правильно, я ошибся дважды. Огромное спасибо за замечание и подробный комментарий!
Сначала я написал то, что знал и то, что мы у себя в проекте используем (точнее не используем таймзоны в постгресе), а потом, на всякий случай, полез в документацию и удивился, увидев там «PostgreSQL allows you to specify… а full time zone name, for example America/New_York». Подумал, что я осёл и на тот момент, когда я разрабатывал структуру базы данных я просто упустил этот момент из виду и мне стало стыдно.
Теперь я вспомнил, почему я этого не помню и почему мы у себя в календаре не используем «timestamp with timezone» — потому, что таймзоны в постгресе просто никакие и я вообще забыл про их существование, сосредоточившись за эти годы на поддержку таймзон в коде.
Всё равно нет мне оправдания. Буду страдать :-)
У нас в mail.ru есть специальная геобаза, поддерживаемая в актуальном состоянии. Мы используем её для определения города пользователя по его IP (в базе мы храним город) и для определения таймзоны по городу (и, соответственно, по IP). С городами, кстати, тоже есть проблемы — были случаи, когда города переходили от одной страны к другой, и тогда нам по цепочке нужно было менять таймзону для пользователя, город которого не поменялся. Всякое бывает.
Конечно, наша геобаза используется только внутри компании и я не могу ничего про неё говорить, однако недавно я отвечал на похожий вопрос, и нашёл модуль pythonhosted.org/python-geoip/, который позволяет определять таймзону по IP:
Они используют геобазу от MaxMind. Я не знаю, насколько она актуальна, но беглое изучение документации показало, что там есть координаты и таймзона, и я думаю, что из этого модуля можно получить интересующую информацию.
Ещё раз спасибо за комментарий :-)
Сначала я написал то, что знал и то, что мы у себя в проекте используем (точнее не используем таймзоны в постгресе), а потом, на всякий случай, полез в документацию и удивился, увидев там «PostgreSQL allows you to specify… а full time zone name, for example America/New_York». Подумал, что я осёл и на тот момент, когда я разрабатывал структуру базы данных я просто упустил этот момент из виду и мне стало стыдно.
Теперь я вспомнил, почему я этого не помню и почему мы у себя в календаре не используем «timestamp with timezone» — потому, что таймзоны в постгресе просто никакие и я вообще забыл про их существование, сосредоточившись за эти годы на поддержку таймзон в коде.
Всё равно нет мне оправдания. Буду страдать :-)
У нас в mail.ru есть специальная геобаза, поддерживаемая в актуальном состоянии. Мы используем её для определения города пользователя по его IP (в базе мы храним город) и для определения таймзоны по городу (и, соответственно, по IP). С городами, кстати, тоже есть проблемы — были случаи, когда города переходили от одной страны к другой, и тогда нам по цепочке нужно было менять таймзону для пользователя, город которого не поменялся. Всякое бывает.
Конечно, наша геобаза используется только внутри компании и я не могу ничего про неё говорить, однако недавно я отвечал на похожий вопрос, и нашёл модуль pythonhosted.org/python-geoip/, который позволяет определять таймзону по IP:
from geoip import geolite2
match = geolite2.lookup('17.0.0.1')
match.timezone
'America/Los_Angeles'
Они используют геобазу от MaxMind. Я не знаю, насколько она актуальна, но беглое изучение документации показало, что там есть координаты и таймзона, и я думаю, что из этого модуля можно получить интересующую информацию.
Ещё раз спасибо за комментарий :-)
Спасибо за ссылку! Они используют вот эту базу от MaxMind: dev.maxmind.com/geoip/geoip2/geolite2/.
Но она, к сожалению, тоже не актуальна — отсутствуют новые зоны Asia/Chita и Asia/Srednekolymsk, а значит, недавняя перетасовка поясов в России там не учтена…
Но она, к сожалению, тоже не актуальна — отсутствуют новые зоны Asia/Chita и Asia/Srednekolymsk, а значит, недавняя перетасовка поясов в России там не учтена…
Нет, таймзоны в Постгресе хорошие, просто он их не хранит :-(
Вот, например, как можно сделать поиск записей, которые нужно «подвинуть» после изменения часовых поясов (если, конечно, в Постгресе актуальная база часовых поясов):
Вот, например, как можно сделать поиск записей, которые нужно «подвинуть» после изменения часовых поясов (если, конечно, в Постгресе актуальная база часовых поясов):
SET TIME ZONE UTC;
CREATE TABLE tztest (
"utc" timestamp with time zone,
"local" timestamp with time zone,
"timezone" character varying
);
-- Вставляем дату и время до перевода часов
INSERT INTO tztest (utc, local, timezone) VALUES
('2014-11-10 12:13:14', '2014-11-10 16:13:14', 'Europe/Moscow');
-- Вставляем дату и время после перевода часов
INSERT INTO tztest (utc, local, timezone) VALUES
('2014-11-10 13:13:14', '2014-11-10 16:13:14', 'Europe/Moscow');
SELECT utc, local, timezone, utc2local, utc2local = local AS ok FROM (
SELECT utc, local, timezone, (utc AT TIME ZONE timezone) AS utc2local FROM tztest
) tzt;
utc | local | timezone | utc2local | ok
------------------------+------------------------+---------------+---------------------+----
2014-11-10 12:13:14+00 | 2014-11-10 16:13:14+00 | Europe/Moscow | 2014-11-10 15:13:14 | f
2014-11-10 13:13:14+00 | 2014-11-10 16:13:14+00 | Europe/Moscow | 2014-11-10 16:13:14 | t
(2 rows)
DROP TABLE tztest;
А может эту «специальную геобазу» того… открыть в виде api? Или хотя бы выложить в виде обновляемых раз в сутки csv-файлов для скачивания?
>В случае изменений часовых поясов, мы можем пройтись по записям для изменившихся таймзон специальным скриптом, и обновить время в UTC, если оно поменялось в результате обновления часового пояса.
Перечитал несколько раз. Может я туплю, простите тогда, но мы тут точно должны обновить время в UTC? А разве не локальное время юзера?
P.S. За статью спасибо, понравилось. Дьявол как всегда…
Перечитал несколько раз. Может я туплю, простите тогда, но мы тут точно должны обновить время в UTC? А разве не локальное время юзера?
P.S. За статью спасибо, понравилось. Дьявол как всегда…
Я рассматриваю случай, когда пользователь изначально задал время в своём часовом поясе. Время в UTC нужно только для того, чтобы облегчить выборку по базе. В случае изменения конфигурации часового пояса, локальное время пользователя останется неизменным (он хотел получить уведомление в 10:00 по Москве, например), но время в UTC для этого локального времени изменится. Поэтому нам нужно обновить его.
Понял. Но ведь двигать значение времи в поле по которому делается выборка тоже небезопасно — можно попасть в ту же ловушку, когда «время еще не наступило», обновляем поле, получаем «время уже прошло»? Что-то тут далеко не просто получается, особенно, если событие попадает в момент перевода часов =)
Интересно, правда ли, что тот же РЖД «внутри» весь живет по одному времени (msk)? В принципе их можно понять.
Интересно, правда ли, что тот же РЖД «внутри» весь живет по одному времени (msk)? В принципе их можно понять.
Вообще, по косвенным признакам РЖД действительно по Москве живет.
Ну, по всей стране и на билетах время московское, по крайней мере.
Ну, по всей стране и на билетах время московское, по крайней мере.
Эм, что значит «внутри»? Вы на вокзале давно были? Открою вам страшную тайну, но по всей России матушке все вокзальные часы показывают одинаковое московское время и никто этого не скрывает.
Совершенно верно, везде есть нюансы, и, например, мы не можем совершенно однозначно и точно перевести время 1:30 ночи в Москве 26 октября 2014 года в UTC. Боль и унижение :-) Однако с этим можно что-то придумать, всё зависит от ситуации. Как я писал в статье:
:-)
никогда не слушайте категоричных утверждений, рекомендующих вам никогда не делать тех или иных вещей
:-)
Соответственно, если мы отправим уведомление пользователю 3 ноября в 5:00 утра по UTC, он получит его в 8:00 утра по Москве
Почему? Это произойдёт только если на сервере время не будет переведено. А если будет — то он получит уведомление как раз в 9 утра. А проблема перевода времени на серверах — это не проблема хранения даты в БД.
Это произойдёт только если на сервере время не будет переведено. А если будет — то он получит уведомление как раз в 9 утра.
Нет. Если интересно разобраться, почему так, пожалуйста, прочитайте ещё раз соответствующий фрагмент статьи, я всё подробно описал :-)
Вообще, выражение «перевод времени на сервере» не имеет никакого смысла. Время на сервере (и на любом другом компьютере — ноутбуке, планшете, телефоне) можно только синхронизировать с сервером точного времени. Переводится время для пользователя, который на данный момент работает в ОС и для которого ОС, согласно настройкам пользователя, переводит внутреннее время в локальное время пользователя. И вот во время этого перевода уже учитывается перевод часов. Нет, конечно, есть исключения, однако мы же говорим о правильных ОС и правильной работе со временем, правда?
Вспоминается видео, а также всякие весёлые вещи типа «эпоха макинтош vs эпоха unix». Также вспоминаются причины, по которым тип datetime2 поддерживает даты только «January 1,1 AD through December 31, 9999 AD», а datetime и вовсе «January 1, 1753, through December 31, 9999».
Да, ссылку на это шикарнейшее видео я давал в своём переводе, к которой аппелирует данная статья. Вообще, конечно, про работу со временем можно говорить бесконечно. Столько всего «прекрасного» придумывают люди, чтобы страдать! :-)
А если дату и время рассчитывать на клиенте (в браузере), а на сервер всегда отправлять в UTC? В таком случае вроде проблем быть не должно? Хотя, конечно, такой вариант не подходит для ряда сценариев, включая ваш сервис напоминаний из примеров.
И спасибо за отличную подборку примеров. Может быть сделать какой-то чек-лист непривычных ситуаций, которые стоит держать в уме при работе с датами?
И спасибо за отличную подборку примеров. Может быть сделать какой-то чек-лист непривычных ситуаций, которые стоит держать в уме при работе с датами?
Насколько я вообще знаю, сложная работа со временем в JS просто невозможна нативными средствами. Например, нельзя однозначно определить таймзону пользователя, можно только получить общую информацию — смещение относительно UTC, включен ли переход на летнее время и т.д. И по этой информации попытаться угадать часовой пояс (что будет просто пальцем в небо). Учитывая огромное количество компьютеров со старыми версиями ОС (пресловутый XP), а так же компьютеров, пользователи которых тупо не ставят обновления (в которых приходят новые настройки часовых поясов), и при проблемах с часами просто переводят их руками, это грозит катастрофой.
Плюс часы могут быть не синхронизированы у пользователя, например, да вообще много разных проблем проявляется в реальных больших проектах где нужна особо аккуратная работа со временем (вроде того же календаря). Поэтому время с клиента (браузера) можно передавать только в UTC (если мы пользуемся нативными способами работы с датой в JS). И то будет возникать куча проблем.
Я могу ошибаться, я не так хорош в JS, как в других вещах, если я не прав, буду рад услышать замечания :-)
Плюс часы могут быть не синхронизированы у пользователя, например, да вообще много разных проблем проявляется в реальных больших проектах где нужна особо аккуратная работа со временем (вроде того же календаря). Поэтому время с клиента (браузера) можно передавать только в UTC (если мы пользуемся нативными способами работы с датой в JS). И то будет возникать куча проблем.
Я могу ошибаться, я не так хорош в JS, как в других вещах, если я не прав, буду рад услышать замечания :-)
Для JS есть библиотека Moment.js
Она умеет преобразовывать даты, в том числе учитывая тайм-зоны. Причем у них есть довольно большой файл для локализации и учета часовых поясов. Но да, согласен, неверные часовые пояса пользователей с легкостью все испортят.
И еще быстрое гугление подсказало мне библиотеку ical.js для парсинга формата iCalendar.
Она умеет преобразовывать даты, в том числе учитывая тайм-зоны. Причем у них есть довольно большой файл для локализации и учета часовых поясов. Но да, согласен, неверные часовые пояса пользователей с легкостью все испортят.
И еще быстрое гугление подсказало мне библиотеку ical.js для парсинга формата iCalendar.
Хорошая статься.
Можете представить себе сколько проблем с этими тайм зонами в системах резервации авиабилетов и управления взлетами.
Можете представить себе сколько проблем с этими тайм зонами в системах резервации авиабилетов и управления взлетами.
Мне кажется вы немного не теми понятиями оперируете, и поэтому все выглядит так сложно. Гораздо проще оперировать понятием timestamp — количество миллисекунд с 1 января 1970 года 00:00 UTC. Это с точностью до миллисекунды соответствует определенному моменту времени во вселенной, не зависимо ни от каких таймзон. Тем более почти все СУБД и языки представляют дату в памяти именно так. Сравнивать timestamp-ы между собой так же просто как числа, тут тоже не нужны никакие таймзоны.
Таймзоны становятся нужны когда вам нужно отобразить дату для пользователя, получить дату от пользователя, оперировать частями даты (час, минута, день, месяц, год, и т.п.). В таком случае есть 2 подхода:
1. Вы можете использовать везде одну таймзону (серверную), сказать пользователю что все отображается в этой таймзоне, все операции в запросах БД и в программе по умолчанию оперируют в серверной таймзоне, телодвижений практически не требуется.
2. Где-то хранить разные таймзоны, они могут быть привязаны к пользователю, могут быть привязаны отдельно к каждому полю с датой в БД. Благо многие СУБД и языки поддерживают типы данных timezone и timestamp with timezone.
Сравнивать timestamp-ы с разными таймзонами все так же просто, внутренний timestamp ведь одинаков, это все еще абсолютный момент времени, просто с дополнительной информацией о смещении. Для отображения, конвертации из строки, операций с частями даты как правило существует полный набор встроенных средств в СУБД или в библиотеку языка программирования. Все переходы на летнее/зимнее время, смены часовых поясов обрабатываются автоматически, обновления приходят с обновлениями ОС, СУБД или библиотек, так что при правильно написанном коде заботиться об этом практически не нужно.
Таймзоны становятся нужны когда вам нужно отобразить дату для пользователя, получить дату от пользователя, оперировать частями даты (час, минута, день, месяц, год, и т.п.). В таком случае есть 2 подхода:
1. Вы можете использовать везде одну таймзону (серверную), сказать пользователю что все отображается в этой таймзоне, все операции в запросах БД и в программе по умолчанию оперируют в серверной таймзоне, телодвижений практически не требуется.
2. Где-то хранить разные таймзоны, они могут быть привязаны к пользователю, могут быть привязаны отдельно к каждому полю с датой в БД. Благо многие СУБД и языки поддерживают типы данных timezone и timestamp with timezone.
Сравнивать timestamp-ы с разными таймзонами все так же просто, внутренний timestamp ведь одинаков, это все еще абсолютный момент времени, просто с дополнительной информацией о смещении. Для отображения, конвертации из строки, операций с частями даты как правило существует полный набор встроенных средств в СУБД или в библиотеку языка программирования. Все переходы на летнее/зимнее время, смены часовых поясов обрабатываются автоматически, обновления приходят с обновлениями ОС, СУБД или библиотек, так что при правильно написанном коде заботиться об этом практически не нужно.
Timestamp — это то же время в UTC, просто для удобства работы с ним представленное не в виде объекта, а в виде числа. «Timestamp with timezone» — вообще другое. Попробуйте перевести время «2014-10-26 01:30:00» в таймзоне «Europe/Moscow» в UNIX-timestamp?
Мне кажется, вы не читали статью, простите за грубость.
Мне кажется, вы не читали статью, простите за грубость.
Попробуйте перевести время «2014-10-26 01:30:00» в таймзоне «Europe/Moscow» в UNIX-timestamp?
jsfiddle.net/rq9vwobz/
Тут используется js библиотека moment.js. Для даты в таймзоне 'Europe/Moscow' и в UTC таймзоне внутри хранится один timestamp (по прежнему один момент времени), но разный offset, который влияет на отображение.
Как вы прокомментируете вот это? jsfiddle.net/k2hL2s91/
Москва перешла с UTC+4 на UTC+3, соответственно через секунду после «2014-10-26 01:59:59» стало опять «2014-10-26 01:00:00», далее прошел еще час (3600 секунд) и стало «2014-10-26 02:00:00», что в итоге и дало 3601 секунду в вашем примере. Так как мы имеем одно и то же строковое представление времени для разных моментов времени («2014-10-26 01:00:00» до и после перевода часов), библиотека не может понять какой именно момент вы имеете ввиду и берет например более ранний, что должно быть задокументированно.
Также бывает что из-за перевода часов вперед для какого-то на первый взгляд корректного строкового представления времени нету определенного момента времени (этот час просто пропустили, перевели стрелки), тогда хорошая библиотека должна сообщить об ошибке.
Также бывает что из-за перевода часов вперед для какого-то на первый взгляд корректного строкового представления времени нету определенного момента времени (этот час просто пропустили, перевели стрелки), тогда хорошая библиотека должна сообщить об ошибке.
Мне кажется вы немного не теми понятиями оперируете, и поэтому все выглядит так сложно. Гораздо проще оперировать понятием timestamp
То есть UNIX-timestamp === UTC, следовательно всё, что я писал в статье — актуально (если заменяем в тексте «время в UTC» на «timestamp», ничего не поменяется).
Согласен, но в таком случае некоторые моменты выглядят не очень логично, нарпимер
Это совершенно излишне, лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону. Преимущества я уже называл, сравнивать с другими timestamp with timezone-ами очень легко, ничего не надо конвертировать, просто сравнение двух чисел. Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
И вещи вроде «перевод в UTC», «перевод в локальную таймзону» смысла не несут, всегда хранится timestamp и опционально таймзона, которая используется для некоторых операций, в таком случае конвертация не нужна в принципе. Мы просто применяем таймзону к timestamp-у.
Я не говорю что что-то неверно в вашей статье, я говорю что представлять дату не в виде строки или объекта (как в вашей статье), а в виде числа гораздо удобнее и проще для понимания.
Если вам нужно хранить время в прошлом или в будущем, сохраняйте локальное время пользователя, а рядом сохраняйте его таймзону. А ещё лучше, так, чтобы наверняка, сохраняйте географическое положение пользователя. Если нужно делать выборки по этому времени, сохраняйте рядом время в UTC, и обновляйте это время при изменении информации о часовом поясе.
Это совершенно излишне, лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону. Преимущества я уже называл, сравнивать с другими timestamp with timezone-ами очень легко, ничего не надо конвертировать, просто сравнение двух чисел. Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
И вещи вроде «перевод в UTC», «перевод в локальную таймзону» смысла не несут, всегда хранится timestamp и опционально таймзона, которая используется для некоторых операций, в таком случае конвертация не нужна в принципе. Мы просто применяем таймзону к timestamp-у.
Я не говорю что что-то неверно в вашей статье, я говорю что представлять дату не в виде строки или объекта (как в вашей статье), а в виде числа гораздо удобнее и проще для понимания.
Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
Пример с Читой очень хорош и показателен.
лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону
Всё так и есть. Если база данных позволяет хранить дату-время с таймзоной (как, например, postgresql), то я, навскидку, не вижу никаких проблем. При условии, что мы своевременно обновляем таймзону в базе данных и при условии, что таймзоны в коде абсолютно идентичны таймзонам в базе данных, и при условии, что обновление таймзон в базе данных происходит единовременно с обновлением таймзон в коде на всех серверах проекта (которых может быть тысячи).
Наверное, следовало написать об этом в статье, чтобы этот момент не вызывал столько вопросов. Суть ведь вовсе не в том, в каком поле мы храним информацию, а в том, в каком виде мы её храним. Одно поле «timestamp with timezone» или два поля «timestamp» + «timezone» — всё это особенности реализации конкретного проекта и вы, порой, бываете сильно ограничены в выборе тех или иных инструментов, той или иной базы данных. В любом случае, замечание резонное, принимается.
Представлять дату в виде строки, а не числа, проще для человека. Представлять дату в виде объекта (а не числа) проще при работе с датами в коде (получить номер месяца, день недели и прочие штуки). Впрочем, это уже совсем другая история :-)
Это с точностью до миллисекунды соответствует определенному моменту времени во вселенной
Посмотрите, всё-таки, видео.
Посмотрел. Противоречий с тем что я написал не нашел. Если вы про leap second — с этим как я понял пока вообще все сложно, мало где она поддерживается. И наличие leap second никак не противоречит концепции timestamp как количества миллисекунд с определенного момента времени. Просто преобразование из timestamp в форматированную дату должно будет поддерживать историю изменений leap second.
Длительность секунды (а следовательно и миллисекунды) строго константна, и определена как 9192631770 периодов излучения атома цезия-133, так что свое утверждение я считаю вполне обоснованным.
Вот длительность минуты из-за leap second может различаться, что безусловно создает массу проблем.
Вот длительность минуты из-за leap second может различаться, что безусловно создает массу проблем.
Не всегда :-) www.youtube.com/watch?v=-5wpm-gesOY#t=555 — вот с этого момента рассказывается про идею «размазывания» корректировочной секунды в течение всего дня.
Да, интересная вещь. Но это скорее на очередной костыль похоже, который просто чисто технически приносит меньше неприятностей. UTC основан все-таки на атомной секунде. И в идеале программная реализация UTC должна знать что между «2012-06-30 23:59:59 UTC» и «2012-07-01 00:00:00 UTC» прошло 2 секунды.
Да, 21 июля 2014 года Государственная дума Российской Федерации приняла законопроект об отмене летнего времени. Согласно этому закону, с 26 октября 2014 года, смещение для таймзоны Europe/Moscow стало «UTC+3» вместо «UTC+4» (а ещё переход на летнее время отменили, но речь сейчас не об этом). Соответственно, если мы отправим уведомление пользователю 3 ноября в 5:00 утра по UTC, он получит его в 8:00 утра по Москве, и я уверен, что пользователь будет недоумевать, ведь он просил, чтобы уведомление пришло ему ровно в девять утра.
Только вы забыли, что 26 октября 2014 года стрелки часов будут переведены на 1 час назад, и таким образом 9:00 3.11.2014 станут 8:00 3.11.2014. Если приводить время к UTC, то тут будет все логично: 3.11.2014 9:00 +004 → 3.11.2014 5:00 +000 → 3.11.2014 8:00 +003
Теперь вы делаете предположение, что пользователь будет негодовать. Рассмотрим его подробнее.
Предположим, что пользователь ставит будильник за 1 час, чтоб не проспать на работу к 10:00, тогда, действительно, он проснется на 1 час раньше и будет негодовать.
А теперь предположим, что пользователь принимает лекарства: 1 таблетку каждые 10 дней (ошибка ± 10 минут смертельна). Предыдущую таблетку он принял 24.10.2014 9:00 +004. Следующую таблетку ему надо принять ровно через 10 дней: 3.11.2014 8:00 +003. В этом случае пользователь будет бесконечно рад, что «умный» календарь не сдвинул напоминание на 1 час вперед.
Понимаете к чему я клоню? Нельзя решать за пользователя, что для него важно, а что нет.
В статье вы пытаетесь «зашить» бизнес-логику в формат хранения данных. Приведение времени события к UTC или хранение тайм-зоны — достаточно. Все остальное можно (или даже нужно) делать в алгоритмах обработки.
С уважением, бывший разработчик календаря Onlyoffice (former Teamlab).
Ничего из того, что вы написали, не противоречит моей статье :-)
Вот моя основная мысль (позволю себе процитировать её ещё раз):
Случай с таблеткой настолько уникален и вырожден, что я не могу придумать ни одного подходящего варианта из реальной жизни. И я не слышал вообще ни одной жалобы от пользователя относительно того, что все события в календаре остались на своих местах (по локальному времени), хотя полгода назад он задавал их в UTC. Понимаете, к чему я клоню? Подавляющее большинство пользователей ожидает, что если они поставили событие на 10 утра, оно произойдёт в 10 утра, даже если поменяется часовой пояс.
Мы не можем оправдываться перед пользователями тем, что они должны были знать про закон о переводе часов, должны были зайти в наш календарь и сами должны были передвинуть все события после 26 октября на час вперёд. Если мы скажем им, что мы не могли решать за них, что важно, а что нет, это будет выглядеть совершенно глупо, и в таком случае я буду первый, кого уволят с работы и я тоже буду «бывшим разработчиком календаря».
Кстати, из-за странного бага в связке iCal у нас в некоторых случаях некоторые события сдвинулись назад (iCal переписал их поверх старых с той датой, которая, как он думал, была правильная). И вот тут-то каждый пользователь счёл своим долгом пожаловаться нам, что мы — уроды, и не можем сделать нормальный календарь, что нам следовало бы следить за законами о переводах часов и что нас всех следует уволить.
А тот один пользователь на миллион, которому нужно вовремя принять таблетку, я думаю, он озаботится тем, чтобы воспользоваться специальными для этого инструментами и таймерами.
С уважением к коллеге, Владимир.
Вот моя основная мысль (позволю себе процитировать её ещё раз):
Вывод можно сделать простой и совершенно банальный: никогда не слушайте категоричных утверждений, рекомендующих вам никогда не делать тех или иных вещей. Всегда продумывайте и прорабатывайте все возможные варианты, особо внимательно прорабатывайте архитектуру проекта, пишите качественные тесты и поддерживайте их в актуальном состоянии.
Случай с таблеткой настолько уникален и вырожден, что я не могу придумать ни одного подходящего варианта из реальной жизни. И я не слышал вообще ни одной жалобы от пользователя относительно того, что все события в календаре остались на своих местах (по локальному времени), хотя полгода назад он задавал их в UTC. Понимаете, к чему я клоню? Подавляющее большинство пользователей ожидает, что если они поставили событие на 10 утра, оно произойдёт в 10 утра, даже если поменяется часовой пояс.
Мы не можем оправдываться перед пользователями тем, что они должны были знать про закон о переводе часов, должны были зайти в наш календарь и сами должны были передвинуть все события после 26 октября на час вперёд. Если мы скажем им, что мы не могли решать за них, что важно, а что нет, это будет выглядеть совершенно глупо, и в таком случае я буду первый, кого уволят с работы и я тоже буду «бывшим разработчиком календаря».
Кстати, из-за странного бага в связке iCal у нас в некоторых случаях некоторые события сдвинулись назад (iCal переписал их поверх старых с той датой, которая, как он думал, была правильная). И вот тут-то каждый пользователь счёл своим долгом пожаловаться нам, что мы — уроды, и не можем сделать нормальный календарь, что нам следовало бы следить за законами о переводах часов и что нас всех следует уволить.
А тот один пользователь на миллион, которому нужно вовремя принять таблетку, я думаю, он озаботится тем, чтобы воспользоваться специальными для этого инструментами и таймерами.
В статье вы пытаетесь «зашить» бизнес-логику в формат хранения данных.Нет.
Приведение времени события к UTC или хранение тайм-зоны — достаточно.Да нет же =) Ну прочитайте же статью, я ведь написал там про то, что произойдёт, если мы будем хранить время в UTC, и почему этого недостаточно :-)
С уважением к коллеге, Владимир.
Пользователь может переехать в другую часть света, будете ли пересчитывать напоминалки в календаре на его локальное время? Напоминалка может быть привязана польщователем к чему-то локальному (будильник), а может и к чему-то глобальному (совещание по скайпу с коллегой из другого города)
Это совсем другие вопросы. Возможно, будем пересчитывать, да, всё зависит от задачи. Может, не будем (если найдётся другое приемлимое для, пардон, хайлоада, решение).
Главное, чтобы пользователь получилот нас то, чего он ожидает.
Главная тема моей статьи — опровергнуть высказывание «всегда храните время только в UTC и всегда работайте со временем только в UTC». Что бывают случаи, когда время в UTC всё ломает, хотя в подавляющем большинстве случаев можно спокойно использовать UTC и вообще не иметь никаких проблем. Мне кажется, у меня это получилось :-)
Главное, чтобы пользователь получилот нас то, чего он ожидает.
Главная тема моей статьи — опровергнуть высказывание «всегда храните время только в UTC и всегда работайте со временем только в UTC». Что бывают случаи, когда время в UTC всё ломает, хотя в подавляющем большинстве случаев можно спокойно использовать UTC и вообще не иметь никаких проблем. Мне кажется, у меня это получилось :-)
Кейс со скайпом весьма актуален.
Прочитал 2 раза. Все кейсы, что вы рассматривали, я смог бы решить с помощью приведения времени событий к UTC для хранения, и хранения тайм-зоны пользователя, как свойство в профиле.
От себя бы добавил нулевой совет:
0) Никогда, ни при каких обстоятельствах не храните/обрабатывайте/etc. время событий в локальном формате (т.е. без явного учитывания тайм-зоны, либо UTC).
В любой момент времени вашим сайтом/сервисом/скриптом/библиотекой/… могут начать пользоваться люди из другой страны или тайм-зоны, и тогда вам придется переделывать существующее, вероятнее всего, применяя «костыли», вместо движения вперед.
От себя бы добавил нулевой совет:
0) Никогда, ни при каких обстоятельствах не храните/обрабатывайте/etc. время событий в локальном формате (т.е. без явного учитывания тайм-зоны, либо UTC).
В любой момент времени вашим сайтом/сервисом/скриптом/библиотекой/… могут начать пользоваться люди из другой страны или тайм-зоны, и тогда вам придется переделывать существующее, вероятнее всего, применяя «костыли», вместо движения вперед.
Спасибо! Про нулевой совет — полностью согласен, так и делаем :-)
Если все рассмотренные мною сценарии можно привести к хранению времени события в UTC (плюс хранению таймзоны пользователя), то как бы вы решили самый первый случай с учётом того, что произошло на самом деле (изменение таймзоны «Europe/Moscow»)? Мне правда интересно, я для того и написал статью, чтобы обсудить эти вопросы с умными людьми.
Если все рассмотренные мною сценарии можно привести к хранению времени события в UTC (плюс хранению таймзоны пользователя), то как бы вы решили самый первый случай с учётом того, что произошло на самом деле (изменение таймзоны «Europe/Moscow»)? Мне правда интересно, я для того и написал статью, чтобы обсудить эти вопросы с умными людьми.
пользователь из Москвы зашёл на наш сайт 2 марта 2014 года и создал напоминание на 09:00 утра 3 ноября 2014 годаПри условии, что получить напоминание он должен в 9:00 утра 3 ноября 2014 года по Москве.
Я бы так решил:
После смены тайм-зоны для всех пользователей, кого это затрагивает (информация из профиля), вывести уведомление (или вариации — email/...), что произошла смена тайм-зоны, которая затрагивает созданные ими события (список), и если это интерактивный сеанс, то предложить варианты: (default) сдвинуть время событий, либо оставить как есть, либо пересоздать события со сдвигом времени (если повторяющиеся),… варианты.
После смены тайм-зоны для всех пользователей, кого это затрагивает (информация из профиля), вывести уведомление (или вариации — email/...), что произошла смена тайм-зоны, которая затрагивает созданные ими события (список), и если это интерактивный сеанс, то предложить варианты: (default) сдвинуть время событий, либо оставить как есть, либо пересоздать события со сдвигом времени (если повторяющиеся),… варианты.
На мой взгляд, это не решение проблемы, а попытка залечить симптомы. Попытался навскидку написать, почему я не принял бы такое решение в живом проекте:
1. Но зачем что-то спрашивать у пользователя, если в данном конкретном случае (Europe/Moscow) можно сделать всё совершенно незаметно для него?
2. Что произойдёт, если в момент сдвига времени событий упадёт программа/скрипт и часть событий будут сдвинуты, а часть — нет?
— Повторно сдвигать? Как узнать, что сдвинуто, а что — нет?
— Не сдвигать? Тогда часть данных будет не обработана.
3. Пересоздавать события не всегда вариант (либо локи на записи, либо пользователь может не получить своих данных), опять же, что делать, если что-то упадёт?
4. В случае, если у нас огромная база данных (сотни гигабайт только таблица с событиями) и если все пользователи начнут сдвигать свои события одновременно, у нас будут проблемы. «Специальный скрипт», о котором я говорил в статье, сделает это аккуратно, постепенно и равномерно для всех событий подряд, сам заботясь о нагрузке на базу. Более того, его можно запускать повторно, ведь оригинальные данные не меняются.
5. Такая схема работы очень плохо тестируется.
В общем, простите, но в определённых случаях (надёжный, нагруженный проект) такой вариант нежизнеспособен и грозит порчей данных, хотя я вполне допускаю приемлимость такого решения для большинства сервисов в большинстве ситуаций.
1. Но зачем что-то спрашивать у пользователя, если в данном конкретном случае (Europe/Moscow) можно сделать всё совершенно незаметно для него?
2. Что произойдёт, если в момент сдвига времени событий упадёт программа/скрипт и часть событий будут сдвинуты, а часть — нет?
— Повторно сдвигать? Как узнать, что сдвинуто, а что — нет?
— Не сдвигать? Тогда часть данных будет не обработана.
3. Пересоздавать события не всегда вариант (либо локи на записи, либо пользователь может не получить своих данных), опять же, что делать, если что-то упадёт?
4. В случае, если у нас огромная база данных (сотни гигабайт только таблица с событиями) и если все пользователи начнут сдвигать свои события одновременно, у нас будут проблемы. «Специальный скрипт», о котором я говорил в статье, сделает это аккуратно, постепенно и равномерно для всех событий подряд, сам заботясь о нагрузке на базу. Более того, его можно запускать повторно, ведь оригинальные данные не меняются.
5. Такая схема работы очень плохо тестируется.
В общем, простите, но в определённых случаях (надёжный, нагруженный проект) такой вариант нежизнеспособен и грозит порчей данных, хотя я вполне допускаю приемлимость такого решения для большинства сервисов в большинстве ситуаций.
1. Но зачем что-то спрашивать у пользователя, если в данном конкретном случае (Europe/Moscow) можно сделать всё совершенно незаметно для него?
В моем понимании — это ключевой вопрос. Пользователь должен знать, что его события изменились. У пользователя должен быть выбор.
Все остальное решается транзакциями, очередями и пр. В настоящее время существует много технических решений.
И ещё хочу обратить внимание — сам характер бизнеса и стоимость решения могут накладывать ограничения.
Пользователь должен знать, что его события изменились. У пользователя должен быть выбор.
В том-то и дело, что они вообще не изменились :-) И я не согласен про «пользователь должен знать», но тут вообще два разных равноправных подхода, и смысла спорить, наверное, нет.
Если пользователь поставил будильник на 8 утра, чтобы к 9 оказаться на работе, то с его точки зрения никаких изменений с событиями не произошло, и подобный вопрос его крайне озадачит.
Ещё три подводных камня:
— Нарушение временного континуума в момент перевода часов (обсудили чуть выше)
— Система дат 1904
— Секунда координации
Кстати, самый рейтинговый ответ в Stack Overflow посвящён именно часовым поясам. Джону Скиту уже пришлось редактировать свой ответ 2 раза из-за того, что часовые пояса продолжают меняться…
— Нарушение временного континуума в момент перевода часов (обсудили чуть выше)
— Система дат 1904
— Секунда координации
Кстати, самый рейтинговый ответ в Stack Overflow посвящён именно часовым поясам. Джону Скиту уже пришлось редактировать свой ответ 2 раза из-за того, что часовые пояса продолжают меняться…
То есть один из самых рейтинговых. Есть ещё круче.
Спасибо за ссылки! Отличное дополнение к статье :-)
Я не пытался составить полный перечень проблем, просто хотел обратить внимание, что бездумное следование чьим-то советам может привести к страданиям. Хотел на примерах показать некоторые из подводных камней.
Я не пытался составить полный перечень проблем, просто хотел обратить внимание, что бездумное следование чьим-то советам может привести к страданиям. Хотел на примерах показать некоторые из подводных камней.
Всё правильно, со временем надо быть осторожным.
Ещё один пример казуса с временными зонами:
ДНР (Донецк) решила, что у них в Донецке московское время. Украина (Киев) решила, что у них в Донецке время на час меньше Московского. На одной и той же территории.
Задача: если в календаре стоит «будить каждый день в 13 часов на обед» — когда должен сработать будильник? На работе у сепаратиста время московское, дома бендеровка-тёща поставила киевское. В выходные он дома, в рабочие дни на работе. В форумах будет та же проблема — что бы он не поставил, время будет правильное только с какой-то вероятностью, в зависимости от того, на чьём компьютере заходить на форум.
Украина вообще набор казусов — РЖД недавно прекратила продажу билетов на Украину, так как не смола справиться с временными зонами:
«В связи с отсутствием окончательного решения о переходе Украины в марте 2013 года на летнее время РЖД вынуждено приостановить продажу проездных документов на поезда дальнего следования, в том числе прицепные и беспересадочные вагоны в сообщении c Украиной, отправлением с территории России с 30 марта 2013 года»
С постгресом тоже не всё здорово. EnterpriseDB недавно вовремя не обновила для windows дистрибутива файл зон, и время считалось неправильно.
Ещё один пример казуса с временными зонами:
ДНР (Донецк) решила, что у них в Донецке московское время. Украина (Киев) решила, что у них в Донецке время на час меньше Московского. На одной и той же территории.
Задача: если в календаре стоит «будить каждый день в 13 часов на обед» — когда должен сработать будильник? На работе у сепаратиста время московское, дома бендеровка-тёща поставила киевское. В выходные он дома, в рабочие дни на работе. В форумах будет та же проблема — что бы он не поставил, время будет правильное только с какой-то вероятностью, в зависимости от того, на чьём компьютере заходить на форум.
Украина вообще набор казусов — РЖД недавно прекратила продажу билетов на Украину, так как не смола справиться с временными зонами:
«В связи с отсутствием окончательного решения о переходе Украины в марте 2013 года на летнее время РЖД вынуждено приостановить продажу проездных документов на поезда дальнего следования, в том числе прицепные и беспересадочные вагоны в сообщении c Украиной, отправлением с территории России с 30 марта 2013 года»
С постгресом тоже не всё здорово. EnterpriseDB недавно вовремя не обновила для windows дистрибутива файл зон, и время считалось неправильно.
Ну так и чем ваш вывод отличается от вывода Tom Scott?
What you learn after dealing with timezones is that what you do is you put away your code. You don't try to write anything to deal with this. You look at the people who've been there before you. You look at the first people, at the people who dealt with it before, the people who built a spagetti code. You go to them and you thank them very much for making it open source. You give them credit and take what they made. You put it in your program and you never ever look at it again because that way lies madness.
Если вы прочитали только «TL;DR», то ничем. Если вы прочитали всю статью — то всем. Например, тем, что Том рассказывал о работе с таймзонами руками, без библиотек и в конце пришёл к выводу о том, что нужно использовать библиотеки и базы данных таймзон. Я же рассказываю о том, какие могут быть проблемы, если мы будем использовать эти самые библиотеки и базы данных таймзон. Развитие, дополнение, продолжение, так сказать, рассказа Тома :-)
Люди, хранящие время про будущие события, закладываются на очень шаткий фундамент: они предполагают, что госдума не будет менять число часов в сутках, количество дней в неделе, порядок следования натуральных чисел и понятие «завтра». Но это ведь только до тех пор, пока не окажется, что с течением времени дети стареют и умирают, так что для защиты детей от разрушительного воздействия времени следует принять закон о запрете.
Не?
Не?
Есть еще как минимум два прекрасных сценария, когда работа с часовыми поясами доставляет боль и страдание.
1. Время в системе хранится в локальном часовом поясе пользователя с указанием таймзоны. Наступает 26 октября 2014 года, на часах 1:30 ночи. Какое это время в UTC? Совершенно непонятно, потому что в этот день время с часу до двух ночи повторяется дважды, а UTC течет непрерывно. В любой системе, которая вынуждена оперировать с несколькими часовыми поясами одновременно возникает неопределенность, которую нужно решать явно, тем или иным способом.
2. В календаре отмечена регулярная (еженедельная, например) встреча между двумя людьми, находящимися в разных часовых поясах, например, в Москве и Киеве. Для проведения встречи и там и там нужны драгоценные ресурсы переговорных комнат. И вот наступает момент, когда Москва отказывается от перевода часов на зимнее время, а Киев часы переводит. В одном из городов обязательно произойдет смещение времени начала встречи на час — и она пересечется с другими в этой же переговорке, которые были созданы без участия второго города.
Полностью поддерживаю автора, работа с часовыми поясами — это боль и страдание, и очень редко встречающийся навык, что тоже, иногда доставляет неудобства при использовании в работе сторонних библиотек.
1. Время в системе хранится в локальном часовом поясе пользователя с указанием таймзоны. Наступает 26 октября 2014 года, на часах 1:30 ночи. Какое это время в UTC? Совершенно непонятно, потому что в этот день время с часу до двух ночи повторяется дважды, а UTC течет непрерывно. В любой системе, которая вынуждена оперировать с несколькими часовыми поясами одновременно возникает неопределенность, которую нужно решать явно, тем или иным способом.
2. В календаре отмечена регулярная (еженедельная, например) встреча между двумя людьми, находящимися в разных часовых поясах, например, в Москве и Киеве. Для проведения встречи и там и там нужны драгоценные ресурсы переговорных комнат. И вот наступает момент, когда Москва отказывается от перевода часов на зимнее время, а Киев часы переводит. В одном из городов обязательно произойдет смещение времени начала встречи на час — и она пересечется с другими в этой же переговорке, которые были созданы без участия второго города.
Полностью поддерживаю автора, работа с часовыми поясами — это боль и страдание, и очень редко встречающийся навык, что тоже, иногда доставляет неудобства при использовании в работе сторонних библиотек.
В случае с переговорками их нужно бронировать в UTC. а в случае внепланового изменения часовых поясов уведомлять всех забронировавших, что локальное время у кого-то из участников «поехало».
Впрочем, вряд ли кто-то бронирует переговорки более чем за месяц, а обновление базы часовых поясов было доступно заранее.
Впрочем, вряд ли кто-то бронирует переговорки более чем за месяц, а обновление базы часовых поясов было доступно заранее.
Речь о повторяющихся встречах. Такую могли создать и год назад, но она по-прежнему проводится. Проблема даже не в том, что у участников поедет время — это, как правильно замечено, легко решается рассылкой уведомлений. Проблема в том, что при смещении встречи она начинает пересекаться с уже созданными по локальному времени событиями в этой же переговорке. Расписание переговорок обычно очень плотное, и наложение почти гарантированно.
Отдельным пунктом можно долго описывать, как в календарях у сотрудников компании, растянутой на пять часовых поясов, организовать еженедельную общую встречу утром каждого понедельника :)
Отдельным пунктом можно долго описывать, как в календарях у сотрудников компании, растянутой на пять часовых поясов, организовать еженедельную общую встречу утром каждого понедельника :)
Ещё из возможных граблей хотел бы отметить день рождения. По опыту его крайне нежелательно хранить в виде datetime, поскольку различные виджеты выбора даты создают время либо как текущее в UTC, либо как 00:00 в UTC. И то и то — очень неудачные варианты. В первом случае все вообще непредсказуемо, во втором случае день рождения предсказуемо смещается на день при любых таймзонах меньше той, где находился пользователь в момент создания такого события.
На этом погорели разработчики ICQ-протокола (там было много версий, за все не скажу, но пришлось столкнуться). Они хранили дату рождения юзера в unixtime (то есть с точностью до секунды зачем-то)
И совершенно непонятно было — если у человека стоит дата рождения типа 13 марта 01:00 UTC — то у него в России (которая справа от Гринвича) действительно 13 марта. А если человеку повезло родиться в Америке (слева от Гринвича) — то его надо с днем рожденья принято поздравлять 12 марта вообще-то (когда 13-ое наступило только в восточном полушарии).
И совершенно непонятно было — если у человека стоит дата рождения типа 13 марта 01:00 UTC — то у него в России (которая справа от Гринвича) действительно 13 марта. А если человеку повезло родиться в Америке (слева от Гринвича) — то его надо с днем рожденья принято поздравлять 12 марта вообще-то (когда 13-ое наступило только в восточном полушарии).
Кстати, если уж очень хочется хранить так дату, то лучше ставить время 12:00UTC, ущерб минимизируется.
— In 2009, Samoa moved the International Date Line to the other side of its territory, which means that its time zone was changed from GMT–11 to GMT+13. It observes GMT+14 in the southern summer.
— Line Islands of Kiribati observe GMT+14 as standard time.
— Phoenix Islands of Kiribati, Tokelau, and Tonga observe GMT+13 all year round.
— Fiji and New Zealand observe GMT+13 in southern summers.
:-)
— Line Islands of Kiribati observe GMT+14 as standard time.
— Phoenix Islands of Kiribati, Tokelau, and Tonga observe GMT+13 all year round.
— Fiji and New Zealand observe GMT+13 in southern summers.
:-)
Вовсе не нужно хранить локальное время. Достаточно UTC + инфы о часовом поясе или геопозиции. При изменениях в tzdata просто пробегаться по базе и добавлять нужно смещение.
Вовсе не «не нужно». В статье этот способ описан, описаны его достоинства и недостатки. И про пробегание по базе и обновление смещения тоже написано. Прочитайте, пожалуйста, внимательно?
Если вам нужно хранить время в прошлом или в будущем, сохраняйте локальное время пользователя, а рядом сохраняйте его таймзону. А ещё лучше, так, чтобы наверняка, сохраняйте географическое положение пользователя. Если нужно делать выборки по этому времени, сохраняйте рядом время в UTC, и обновляйте это время при изменении информации о часовом поясе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Never say never» или Работаем с таймзонами правильно