我正在用 PHP 编写日历/日程安排应用程序。现在,我会选择您希望事件发生的星期几和时间。我还询问时区并进行相应调整以获取 GMT 的事件时间。
然后我将该时间存储为演出当天午夜的偏移量。这很好,效果很好,但是当我达到夏令时时会发生什么?我不知道发生这种情况时该怎么办。另一个问题是并非所有国家都有夏令时,所以我在那里有点束缚。
我在日历上显示这些事件,所以时间很重要。
处理 DST 真的很痛苦。
对于未来的事件,您应该存储事件发生的位置和本地时间,而不是 GMT 时间。这是因为有时政府会在 DST 开始和停止时发生变化(去年刚刚在美国发生过),然后事件会在 GMT 时发生变化,但不会在当地时间发生变化。
然后,如果您需要在事件发生时通知,请每天收集接下来 24-48 小时的事件,然后将其时间转换为 GMT。为此,您需要一个像这样的位置时区数据库。获取事件发生时每个位置的 GMT 偏移量,并使用它将时间转换为 GMT,然后您就可以准确地知道事件何时发生。
我认为您在 GMT (UTC) 上走在正确的轨道上。每当您在特定时间点发生(或已经发生)某些事件时,使用 UTC 作为您的规范时间戳表示。UTC 不受 DST 规则的影响,因此它是一个很好的、明确的时间点表示。
一旦您制定了明确表示事件日期/时间的策略,那么您就可以很容易地根据哪个时区最容易从您的用户那里接受(或向他们显示)来解决本地化日期/时间的问题。您可能还需要知道并存储事件的时区,但是,因为您以 UTC 格式存储实际的事件日期/时间,如果这更相关,您可以很容易地将其本地化到用户的时区在任何给定的用例中给他们。
这种本地化通常使用您的 SDK 提供的时区库(例如 Java 有 java.util.Calendar)或作为第三方扩展(例如 Python 有 pytz)来执行。我确信 PHP 有一个等价物,但我不熟悉它的库。
这些库通常构建在规则数据库之上,例如Olson Zoneinfo DB。这些规则可能会经常更改,因此您必须随时了解底层数据库的更新,尤其是在您开发真正的全球应用程序时。但是,它们在将晦涩难懂的时区规则外部化方面做得很好,这样您就可以(理论上)更新规则数据库,而无需在 DST 规则在特定区域的变化。
这不是世界上最简单的问题,而且我们必须这样做,但一旦你完成了几次并理解了存储精确时间点表示与本地化关注之间的关注点分离,那么它成为第二天性。
为什么不把责任转嫁给用户。我认为他们需要注册才能使用该应用程序。
让他们在他们的个人资料中说明他们的时间偏移量是多少。像 GMT + 2、GMT - 8 等。他们会知道他们的 DST 设置何时更改并相应地更新他们的个人资料。
当然,这取决于您的用户群。他们可能接受或不接受这种方法。