Scheduling & DST

Контакт с DST является реальной болью.

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

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

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

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

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

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

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

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

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

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