Scheduling & DST

前端 未结 3 1234
星月不相逢
星月不相逢 2021-01-05 02:48

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 accor

3条回答
  •  无人及你
    2021-01-05 03:44

    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.

    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.

    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.

    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.

提交回复
热议问题