Я пишу приложение календаря / планирования в PHP. Сейчас я беру день недели, в который вы хотите, чтобы событие происходило и время. Я также прошу часовой пояс и соответствующим образом настроить, чтобы получить время в GMT.
Затем я сохраняю это время как смещение с полуночи дня шоу. Это прекрасно и отлично работает, но что происходит, когда я нажимаю летнее время? Я не уверен, что делать, когда это произойдет. Другая проблема заключается в том, что не во всех странах есть DST, поэтому я вроде как там привязан.
Я показываю эти события в календаре, поэтому время важно.
Работа с DST – настоящая боль.
Для будущих событий вы должны сохранить местоположение и местное время, в которое должно произойти событие, а не время по Гринвичу. Это происходит потому, что иногда правительства меняются, когда начинается и останавливается летнее время (это только что произошло в прошлом году в США), и события затем меняются в GMT, но не по местному времени.
Затем, если вам нужно уведомить, когда событие происходит, каждый день собирайте события в течение следующих 24-48 часов и затем конвертируйте их в GMT. Для этого вам нужна база данных времени-времени, подобная этой . Получите смещение GMT для каждого местоположения во время события и используйте его для преобразования времени в GMT, тогда вы точно знаете, когда произойдет событие.
Я думаю, что вы на правильном пути с GMT (UTC). Используйте UTC в качестве канонического представления временной метки, когда у вас есть какое-то событие, которое происходит (или произошло) в определенный момент времени . UTC не зависит от правил DST, поэтому он служит отличным, недвусмысленным представлением по времени.
После того, как у вас есть стратегия для однозначного представления даты / времени события, вы можете довольно легко решить проблему локализации даты / времени, исходя из того, какой часовой пояс имеет смысл принимать от ваших пользователей (или отображать их). Вероятно, вам также необходимо знать и хранить часовой пояс события, но, поскольку вы сохраняете фактическую дату / время события в UTC, вы можете легко локализовать его в часовом поясе пользователя, если это более актуально к ним в любом конкретном прецеденте.
Эта локализация обычно выполняется с помощью библиотеки часовых поясов, предоставленной вашим SDK (например, Java имеет java.util.Calendar) или в качестве стороннего расширения (например, Python имеет pytz). Я уверен, что у PHP есть эквивалент, но я не так хорошо знаком с его библиотеками.
Эти библиотеки обычно создаются поверх базы данных правил, такой как база данных Olson Zoneinfo . Эти правила могут изменяться довольно часто, поэтому вам нужно оставаться на вершине обновлений базовой базы данных, особенно если вы разрабатываете действительно глобальное приложение. Тем не менее, они делают хорошую работу по экстернализации эзотерических, туманных правил часовых поясов, чтобы вы (теоретически) обновляли базу данных правил без необходимости выполнять серьезное обновление среды выполнения или вносить существенные изменения кода, когда правила DST в изменение конкретной области.
Это не самая легкая проблема в мире и воняет, что мы должны это делать, но как только вы сделали это несколько раз и почувствовали разделение проблем между сохранением точного представления по времени и интересами локализации, тогда он становится второй натурой.
Почему бы не передать ответственность пользователям. Я предполагаю, что они должны быть зарегистрированы, чтобы использовать приложение.
Просто попросите их сказать в своем профиле, что их смещение во времени. Как GMT + 2, GMT-8 и т. Д. Они будут знать, когда изменились их настройки DST и соответственно обновили их профиль.
Конечно, это зависит от вашей базы пользователей. Они могут принять подход или нет.