我正在用 PHP 编写日历/日程安排应用程序.现在，我会选择您希望事件发生的星期几和时间.我还询问时区并进行相应调整以获取 GMT 的事件时间.
I am writing a calendar/scheduling app in PHP. Right now I take the day of the week you want the event to occur on and the time. I also ask for the timezone and adjust accordingly to get the event time in GMT.
然后我将该时间存储为节目当天午夜的偏移量.这很好，效果很好，但是当我达到夏令时时会发生什么?我不知道发生这种情况时该怎么办.另一个问题是并非所有国家都有夏令时，所以我在那里有点束缚.
Then I store that time as an offset from midnight of the day of the show. This is fine and works great, but what happens when I hit daylight savings time? I'm not sure what to do when that happens. The other problem is that not all countries have DST so I'm kind of in a bind there.
我在日历上显示这些事件，所以时间很重要.
I am displaying these events on a calendar, so timing is important.
我认为您在 GMT (UTC) 方面走在了正确的轨道上.每当您在特定时间点发生(或已经发生)某些事件时，使用 UTC 作为您的规范时间戳表示.UTC 不受 DST 规则的影响，因此它是一个很好的、明确的时间点表示.
I think you are on the right track with GMT (UTC). Use UTC as your canonical timestamp representation whenever you have some event that occurs (or has occurred) at a specific point-in-time. UTC is unaffected by DST rules, so it serves as a great, unambiguous point-in-time representation.
一旦您制定了明确表示事件日期/时间的策略，您就可以很容易地解决本地化日期/时间的问题，具体取决于哪个时区最适合接受您的用户(或向他们展示).您可能还需要知道并存储事件的时区，但是，因为您以 UTC 格式存储实际的事件日期/时间，如果这更相关，您可以很容易地将其本地化到用户的时区在任何给定的用例中给他们.
Once you have a strategy for unambiguous representation of the event date/time, then you can pretty easily solve the problem of localizing date/times based on what time zone makes the most sense to accept from your users (or display to them). You probably need to know and store the time zone of the event as well, but, because you're storing the actual event date/time in UTC, you can pretty easily localize it to the time zone of the user if that is more relevant to them in any given use case.
这种本地化通常使用您的 SDK 提供的时区库(例如 Java 有 java.util.Calendar)或作为第三方扩展(例如 Python 有 pytz)来执行.我确定 PHP 有一个等价物，但我对它的库不太熟悉.
This localization is usually performed with a time zone library either provided by your SDK (e.g. Java has java.util.Calendar) or as a third party extension (e.g. Python has pytz). I'm sure PHP has an equivalent, but I'm not as familiar with its libraries.
这些库通常建立在规则数据库之上，例如 Olson Zoneinfo DB.这些规则可能会经常更改，因此您必须随时了解底层数据库的更新，尤其是在您开发真正的全球应用程序时.但是，它们在将深奥、模糊的时区规则外化方面做得很好，因此您可以(理论上)更新规则数据库，而不必在 DST 规则在特定区域的变化.
These libraries are usually built on top of a rules database such as the Olson Zoneinfo DB. These rules can change quite frequently, so you have to stay on top of updates to the underlying database, especially if you are developing a truly global application. However, they do a good job of externalizing the esoteric, nebulous time zone rules so that you can (in theory) update the rules database without have to perform a major upgrade of your runtime environment or make significant code changes when the DST rules in a particular area change.
这不是世界上最简单的问题，而且我们不得不这样做，但一旦你完成了几次，并理解了存储精确时间点表示与关注点之间的关注点分离，本地化，然后它就变成了第二天性.
It's not the easiest problem in the world and stinks that we have to do it, but once you've done it a couple times and grok the separation of concerns between storing exact point-in-time representation vs. the concern of localization, then it becomes second nature.
这篇关于调度与夏令时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！