Планирование & DST - PullRequest
       31

Планирование & DST

8 голосов
/ 19 февраля 2009

Я пишу приложение для календаря / планирования на PHP. Прямо сейчас я беру день недели, когда вы хотите, чтобы событие произошло, и время. Я также спрашиваю о часовом поясе и корректирую соответственно, чтобы получить время события в GMT.

Затем я сохраняю это время как смещение от полуночи дня шоу. Это нормально и прекрасно работает, но что произойдет, когда я перейду на летнее время? Я не уверен, что делать, когда это произойдет. Другая проблема заключается в том, что не во всех странах есть летнее время, поэтому я как бы в затруднении.

Я отображаю эти события в календаре, поэтому важно время.

Ответы [ 3 ]

3 голосов
/ 19 февраля 2009

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

Если у вас есть стратегия для однозначного представления даты / времени события, то вы можете довольно легко решить проблему локализации даты / времени в зависимости от того, какой часовой пояс наиболее целесообразно принять от вашего пользователи (или показывать им). Возможно, вам также необходимо знать и хранить часовой пояс события, но, поскольку вы храните фактическую дату / время события в формате UTC, вы можете довольно легко локализовать его в часовом поясе пользователя, если это более актуально. им в любом конкретном случае использования.

Эта локализация обычно выполняется с помощью библиотеки часовых поясов, предоставляемой вашим SDK (например, Java имеет java.util.Calendar) или как стороннее расширение (например, Python имеет pytz). Я уверен, что у PHP есть эквивалент, но я не так хорошо знаком с его библиотеками.

Эти библиотеки обычно создаются поверх базы данных правил, такой как Olson Zoneinfo DB . Эти правила могут изменяться довольно часто, поэтому вы должны следить за обновлениями базовой базы данных, особенно если вы разрабатываете действительно глобальное приложение. Тем не менее, они делают хорошую работу по экстернализации эзотерических, туманных правил часовых поясов, так что вы можете (теоретически) обновить базу данных правил без необходимости значительного обновления среды выполнения или внесения значительных изменений кода, когда правила DST в конкретное изменение области.

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

3 голосов
/ 19 февраля 2009

Работа с DST - это настоящая боль.

Для будущих событий вы должны сохранить местоположение и местное время, когда событие должно произойти, а не время по Гринвичу. Это происходит потому, что иногда правительства меняются, когда начинается и заканчивается летнее время (это произошло в прошлом году в США), а затем события меняются по Гринвичу, но не по местному времени.

Тогда, если вам нужно уведомить, когда событие происходит, каждый день собирайте события в течение следующих 24-48 часов и затем конвертируйте их время в GMT. Для этого вам понадобится база данных местоположения-часового пояса, например , эта . Получите смещение GMT ​​для каждого местоположения во время события и используйте его для преобразования времени в GMT, тогда вы точно знаете, когда произойдет событие.

0 голосов
/ 22 февраля 2009

Почему бы не передать ответственность пользователям. Я предполагаю, что они должны быть зарегистрированы, чтобы использовать приложение.

Просто попросите их указать в своем профиле, какое у них время. Как GMT + 2, GMT - 8 и т. Д. Они будут знать, когда их настройки DST изменились, и соответственно обновят свой профиль.

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

...