我正在用PHP编写日历/日程安排应用程序。现在，我采取您希望事件发生的那一天和时间。我还要求时区并相应调整以获得GMT的活动时间。
然后我将该时间存储为演出当天午夜的偏移量。这很好，效果很好，但是当我达到夏令时时会发生什么？当发生这种情况时，我不确定该怎么做。另一个问题是，并非所有国家都有DST，所以我有点在那里。
我在日历上显示这些事件，所以时机非常重要。
答案 0 :(得分：3)
处理DST是一件非常痛苦的事。
对于未来事件，您应该存储事件发生时的位置和当地时间，而不是GMT时间。这是因为有时候政府会在DST启动和停止时发生变化（去年刚刚在美国发生），然后事件会在GMT中转移，但不会在当地时间转移。
然后，如果您需要在事件发生时通知，则每天收集下一个24-48小时的事件，然后将其时间转换为GMT。为此，您需要一个位置时区数据库，如this one。获取事件发生时每个位置的GMT偏移量，并使用该偏移量将时间转换为GMT，然后确切知道事件何时发生。
答案 1 :(得分：3)
我认为你与GMT（UTC）走在正确的轨道上。只要在特定时间点发生（或已发生）某事件，就使用UTC作为规范时间戳表示。 UTC不受DST规则的影响，因此它可以作为一个很好的，明确的时间点表示。
一旦你有一个明确表示事件日期/时间的策略，那么你可以很容易地解决本地化日期/时间的问题，根据什么时区最有意义接受您的用户（或显示给他们）。您可能还需要知道并存储事件的时区，但是，因为您以UTC格式存储实际事件日期/时间，所以如果更相关，您可以非常轻松地将其本地化到用户的时区在任何给定的用例中给他们。
这种本地化通常使用SDK提供的时区库（例如Java具有java.util.Calendar）或第三方扩展（例如Python具有pytz）来执行。我确信PHP有一个等价物，但我对它的库不熟悉。
这些库通常建立在规则数据库之上，例如Olson Zoneinfo DB。这些规则可能会经常更改，因此您必须始终掌握底层数据库的更新，尤其是在开发真正的全局应用程序时。但是，他们很好地将神秘，模糊的时区规则外部化，以便您（理论上）可以更新规则数据库，而无需执行运行时环境的主要升级或在DST规则中进行重大代码更改。特定地区的变化。
这不是世界上最容易出现的问题，而且我们必须做到这一点很糟糕，但是一旦你完成了这个问题，就会在存储确切的时间点表示与关注点之间分离关注点。本地化，然后它成为第二天性。
答案 2 :(得分：-2)
为什么不将责任转嫁给用户。我认为他们需要注册才能使用该应用程序。
让他们在他们的个人资料中说出他们的时间偏移是什么。像GMT + 2，GMT - 8等。他们会知道他们的DST设置何时更改并相应地更新他们的个人资料。
当然，这取决于您的用户群。他们可能会接受或不接受。