Если в двух словах: описываемое в статье решение, возможно, хорошо показывает себя в процессе разработки и сразу после запуска. Но через месяц (или даже через год, как повезёт) этим совершенно невозможно будет пользоваться. А уж поддерживать и расширять функционал — так и подавно. Графит (и прочие решения) решает эти проблемы и позволяет сосредоточится на других, более важных и интересных моментах. Впрочем, как «pet project» в качестве небольшого проекта для получения опыта в ключе «как делать ни в коем случае не надо» описываемое в статье решение вполне себе ок.
Соберите свою лигу людей-которые-играют-по-правилам и принципиально не играйте с «шашлычниками» :)
Мы у себя именно так и поступили — со временем практически все начали играть по правилам, мастерство игры стало расти, а с теми, кто не хочет играть по правилам и, к примеру, крутит штангу больше, чем на 360˚ играть просто неинтересно и скучно — уровень не тот.
— 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.
Да, всё правильно, я ошибся дважды. Огромное спасибо за замечание и подробный комментарий!
Сначала я написал то, что знал и то, что мы у себя в проекте используем (точнее не используем таймзоны в постгресе), а потом, на всякий случай, полез в документацию и удивился, увидев там «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. Я не знаю, насколько она актуальна, но беглое изучение документации показало, что там есть координаты и таймзона, и я думаю, что из этого модуля можно получить интересующую информацию.
Если вы прочитали только «TL;DR», то ничем. Если вы прочитали всю статью — то всем. Например, тем, что Том рассказывал о работе с таймзонами руками, без библиотек и в конце пришёл к выводу о том, что нужно использовать библиотеки и базы данных таймзон. Я же рассказываю о том, какие могут быть проблемы, если мы будем использовать эти самые библиотеки и базы данных таймзон. Развитие, дополнение, продолжение, так сказать, рассказа Тома :-)
Пользователь должен знать, что его события изменились. У пользователя должен быть выбор.
В том-то и дело, что они вообще не изменились :-) И я не согласен про «пользователь должен знать», но тут вообще два разных равноправных подхода, и смысла спорить, наверное, нет.
На мой взгляд, это не решение проблемы, а попытка залечить симптомы. Попытался навскидку написать, почему я не принял бы такое решение в живом проекте:
1. Но зачем что-то спрашивать у пользователя, если в данном конкретном случае (Europe/Moscow) можно сделать всё совершенно незаметно для него?
2. Что произойдёт, если в момент сдвига времени событий упадёт программа/скрипт и часть событий будут сдвинуты, а часть — нет?
— Повторно сдвигать? Как узнать, что сдвинуто, а что — нет?
— Не сдвигать? Тогда часть данных будет не обработана.
3. Пересоздавать события не всегда вариант (либо локи на записи, либо пользователь может не получить своих данных), опять же, что делать, если что-то упадёт?
4. В случае, если у нас огромная база данных (сотни гигабайт только таблица с событиями) и если все пользователи начнут сдвигать свои события одновременно, у нас будут проблемы. «Специальный скрипт», о котором я говорил в статье, сделает это аккуратно, постепенно и равномерно для всех событий подряд, сам заботясь о нагрузке на базу. Более того, его можно запускать повторно, ведь оригинальные данные не меняются.
5. Такая схема работы очень плохо тестируется.
В общем, простите, но в определённых случаях (надёжный, нагруженный проект) такой вариант нежизнеспособен и грозит порчей данных, хотя я вполне допускаю приемлимость такого решения для большинства сервисов в большинстве ситуаций.
Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
Пример с Читой очень хорош и показателен.
лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону
Всё так и есть. Если база данных позволяет хранить дату-время с таймзоной (как, например, postgresql), то я, навскидку, не вижу никаких проблем. При условии, что мы своевременно обновляем таймзону в базе данных и при условии, что таймзоны в коде абсолютно идентичны таймзонам в базе данных, и при условии, что обновление таймзон в базе данных происходит единовременно с обновлением таймзон в коде на всех серверах проекта (которых может быть тысячи).
Наверное, следовало написать об этом в статье, чтобы этот момент не вызывал столько вопросов. Суть ведь вовсе не в том, в каком поле мы храним информацию, а в том, в каком виде мы её храним. Одно поле «timestamp with timezone» или два поля «timestamp» + «timezone» — всё это особенности реализации конкретного проекта и вы, порой, бываете сильно ограничены в выборе тех или иных инструментов, той или иной базы данных. В любом случае, замечание резонное, принимается.
Представлять дату в виде строки, а не числа, проще для человека. Представлять дату в виде объекта (а не числа) проще при работе с датами в коде (получить номер месяца, день недели и прочие штуки). Впрочем, это уже совсем другая история :-)
Мне кажется вы немного не теми понятиями оперируете, и поэтому все выглядит так сложно. Гораздо проще оперировать понятием timestamp
То есть UNIX-timestamp === UTC, следовательно всё, что я писал в статье — актуально (если заменяем в тексте «время в UTC» на «timestamp», ничего не поменяется).
Спасибо! Про нулевой совет — полностью согласен, так и делаем :-)
Если все рассмотренные мною сценарии можно привести к хранению времени события в UTC (плюс хранению таймзоны пользователя), то как бы вы решили самый первый случай с учётом того, что произошло на самом деле (изменение таймзоны «Europe/Moscow»)? Мне правда интересно, я для того и написал статью, чтобы обсудить эти вопросы с умными людьми.
пользователь из Москвы зашёл на наш сайт 2 марта 2014 года и создал напоминание на 09:00 утра 3 ноября 2014 года
При условии, что получить напоминание он должен в 9:00 утра 3 ноября 2014 года по Москве.
Это совсем другие вопросы. Возможно, будем пересчитывать, да, всё зависит от задачи. Может, не будем (если найдётся другое приемлимое для, пардон, хайлоада, решение).
Главное, чтобы пользователь получилот нас то, чего он ожидает.
Главная тема моей статьи — опровергнуть высказывание «всегда храните время только в UTC и всегда работайте со временем только в UTC». Что бывают случаи, когда время в UTC всё ломает, хотя в подавляющем большинстве случаев можно спокойно использовать UTC и вообще не иметь никаких проблем. Мне кажется, у меня это получилось :-)
Если в двух словах: описываемое в статье решение, возможно, хорошо показывает себя в процессе разработки и сразу после запуска. Но через месяц (или даже через год, как повезёт) этим совершенно невозможно будет пользоваться. А уж поддерживать и расширять функционал — так и подавно. Графит (и прочие решения) решает эти проблемы и позволяет сосредоточится на других, более важных и интересных моментах. Впрочем, как «pet project» в качестве небольшого проекта для получения опыта в ключе «как делать ни в коем случае не надо» описываемое в статье решение вполне себе ок.
Если тема действительно интересна, начать копать нужно, как минимум, с изучения исходников питона, но если это слишком сложно, то можно просто погуглить. Вот первая достаточно интересная ссылка по теме: stackoverflow.com/questions/132988/is-there-a-difference-between-and-is-in-python
Мы у себя именно так и поступили — со временем практически все начали играть по правилам, мастерство игры стало расти, а с теми, кто не хочет играть по правилам и, к примеру, крутит штангу больше, чем на 360˚ играть просто неинтересно и скучно — уровень не тот.
А за статью спасибо, молодцы!
— 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.
:-)
Спасибо за замечание и исправление!
Так получилось, что сначала подробно ответил на похожий вопрос в комментарии ниже, а потом увидел этот.
Сначала я написал то, что знал и то, что мы у себя в проекте используем (точнее не используем таймзоны в постгресе), а потом, на всякий случай, полез в документацию и удивился, увидев там «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. Я не знаю, насколько она актуальна, но беглое изучение документации показало, что там есть координаты и таймзона, и я думаю, что из этого модуля можно получить интересующую информацию.
Ещё раз спасибо за комментарий :-)
В том-то и дело, что они вообще не изменились :-) И я не согласен про «пользователь должен знать», но тут вообще два разных равноправных подхода, и смысла спорить, наверное, нет.
1. Но зачем что-то спрашивать у пользователя, если в данном конкретном случае (Europe/Moscow) можно сделать всё совершенно незаметно для него?
2. Что произойдёт, если в момент сдвига времени событий упадёт программа/скрипт и часть событий будут сдвинуты, а часть — нет?
— Повторно сдвигать? Как узнать, что сдвинуто, а что — нет?
— Не сдвигать? Тогда часть данных будет не обработана.
3. Пересоздавать события не всегда вариант (либо локи на записи, либо пользователь может не получить своих данных), опять же, что делать, если что-то упадёт?
4. В случае, если у нас огромная база данных (сотни гигабайт только таблица с событиями) и если все пользователи начнут сдвигать свои события одновременно, у нас будут проблемы. «Специальный скрипт», о котором я говорил в статье, сделает это аккуратно, постепенно и равномерно для всех событий подряд, сам заботясь о нагрузке на базу. Более того, его можно запускать повторно, ведь оригинальные данные не меняются.
5. Такая схема работы очень плохо тестируется.
В общем, простите, но в определённых случаях (надёжный, нагруженный проект) такой вариант нежизнеспособен и грозит порчей данных, хотя я вполне допускаю приемлимость такого решения для большинства сервисов в большинстве ситуаций.
Пример с Читой очень хорош и показателен.
Всё так и есть. Если база данных позволяет хранить дату-время с таймзоной (как, например, postgresql), то я, навскидку, не вижу никаких проблем. При условии, что мы своевременно обновляем таймзону в базе данных и при условии, что таймзоны в коде абсолютно идентичны таймзонам в базе данных, и при условии, что обновление таймзон в базе данных происходит единовременно с обновлением таймзон в коде на всех серверах проекта (которых может быть тысячи).
Наверное, следовало написать об этом в статье, чтобы этот момент не вызывал столько вопросов. Суть ведь вовсе не в том, в каком поле мы храним информацию, а в том, в каком виде мы её храним. Одно поле «timestamp with timezone» или два поля «timestamp» + «timezone» — всё это особенности реализации конкретного проекта и вы, порой, бываете сильно ограничены в выборе тех или иных инструментов, той или иной базы данных. В любом случае, замечание резонное, принимается.
Представлять дату в виде строки, а не числа, проще для человека. Представлять дату в виде объекта (а не числа) проще при работе с датами в коде (получить номер месяца, день недели и прочие штуки). Впрочем, это уже совсем другая история :-)
То есть UNIX-timestamp === UTC, следовательно всё, что я писал в статье — актуально (если заменяем в тексте «время в UTC» на «timestamp», ничего не поменяется).
Если все рассмотренные мною сценарии можно привести к хранению времени события в UTC (плюс хранению таймзоны пользователя), то как бы вы решили самый первый случай с учётом того, что произошло на самом деле (изменение таймзоны «Europe/Moscow»)? Мне правда интересно, я для того и написал статью, чтобы обсудить эти вопросы с умными людьми.
При условии, что получить напоминание он должен в 9:00 утра 3 ноября 2014 года по Москве.
Главное, чтобы пользователь получилот нас то, чего он ожидает.
Главная тема моей статьи — опровергнуть высказывание «всегда храните время только в UTC и всегда работайте со временем только в UTC». Что бывают случаи, когда время в UTC всё ломает, хотя в подавляющем большинстве случаев можно спокойно использовать UTC и вообще не иметь никаких проблем. Мне кажется, у меня это получилось :-)