4 ms·
It's solved, in that I'm never going to do better than zoneinfo and I'm not going to go crazy trying. https://en.wikipedia.org/wiki/Tz_database https://en.wiki
by msla 3y ago
It's solved, in that I'm never going to do better than zoneinfo and I'm not going to go crazy trying.
https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database
https://www.iana.org/time-zones https://www.iana.org/time-zones
I think of this as "difficulty snap back": Things can only get so difficult before everyone punts and uses some external library.
- squeaky-clean 3y agoThe article isn't about implementing your own time zone handling directly. It's about incorrect assumptions you can make when using such a timezone database or library. For example, carefully consider when events need to happen at a fixed time relative to server time (utc) vs user local time. Consider how you handle changes to the timezone database. A timezone change can cause the scheduled time of an event (such as billing) to not exist in that time zone, or for a scheduled time to occur twice. A user changing their timezone setting can cause a similar effect.
- Rafsark 3y agoTimezones are not hard to build. It's indeed the interpretation of your app and the display to your end users that are hard to manage. Think of your birthday: it's not hard for you to set a datetime at your current location to define when your birthday starts. But the birthday wished from your friends might changed based on the interpretation they have and where they are located