Я думаю, что вы на правильном пути с GMT (UTC). Используйте UTC в качестве канонического представления метки времени, когда у вас есть какое-либо событие, которое происходит (или произошло) в определенный момент времени . На UTC не влияют правила DST, поэтому он служит отличным, однозначным представлением на определенный момент времени.
Если у вас есть стратегия для однозначного представления даты / времени события, то вы можете довольно легко решить проблему локализации даты / времени в зависимости от того, какой часовой пояс наиболее целесообразно принять от вашего пользователи (или показывать им). Возможно, вам также необходимо знать и хранить часовой пояс события, но, поскольку вы храните фактическую дату / время события в формате UTC, вы можете довольно легко локализовать его в часовом поясе пользователя, если это более актуально. им в любом конкретном случае использования.
Эта локализация обычно выполняется с помощью библиотеки часовых поясов, предоставляемой вашим SDK (например, Java имеет java.util.Calendar) или как стороннее расширение (например, Python имеет pytz). Я уверен, что у PHP есть эквивалент, но я не так хорошо знаком с его библиотеками.
Эти библиотеки обычно создаются поверх базы данных правил, такой как Olson Zoneinfo DB . Эти правила могут изменяться довольно часто, поэтому вы должны следить за обновлениями базовой базы данных, особенно если вы разрабатываете действительно глобальное приложение. Тем не менее, они делают хорошую работу по экстернализации эзотерических, туманных правил часовых поясов, так что вы можете (теоретически) обновить базу данных правил без необходимости значительного обновления среды выполнения или внесения значительных изменений кода, когда правила DST в конкретное изменение области.
Это не самая легкая проблема в мире, и нам воняет, что мы должны это сделать, но как только вы сделали это пару раз и ухватились за различие между хранением точного представления времени и беспокойством локализация, тогда она становится второй натурой.