Falsehoods programmers believe about time zones
zainrizvi.io
zainrizvi.io
Localities (countries, cities, areas) have official standard time that, to interpret, depends on the point in history (calendar adjustments, DST, leap seconds...). Finding official standard time for any given person anywhere in the world and at any point in history is a hard problem. But it seems they are not trying to solve that general problem.
Time zones, specifically, usually refer to a relatively straightforward concept: "zones" where time matches, usually given using a time offset (most commonly hourly) from the UTC+0000 (closely related to GMT). "Eastern Standard Time" is a localised (to the USA) name for a time zone that would sound totally foreign to anyone not regularly setting up meetings with Americans. Most people would probably think "what time is in the USA right now?" is a non-ambiguous question.
But that ambiguity is exactly what OP wants to solve. It's more of a NLP problem where the context is simply missing ("what's Colorado Springs time?" is a perfectly valid question to ask, just like time zone monikers would be translated everywhere English is not a native language: majority of the world). Even if there were any better standards than IANA, they would not help with implementing a better algorithm, since there is no real need for everyone to learn any official timezone names, and they'd still refer to them using whatever local name there is.
It's important to remember what the goal of "time zones" is. It is to simplify time keeping and cross-referencing between people who come in regular contact. The only true time is astronomical time, but if a person 20mi/30km away was up to 1 minute off (depending on the direction), it would make any coordination very hard. Sure, we're seeing changes in how often people come into regular contact across timezones, but I don't think we are at a tipping point where everyone needs to adjust just yet.
Developing tools for those who do is sure welcome, so I invite the author to get their terminology (and goal) a bit clarified :)
> In a particularly memorable example, a few years ago the Samoan islands wanted to be on the other side of the international date line to get the same weekends as their Australian trading partners. So on midnight Dec 29th, they changed their UTC offset from -11 to +13 UTC, skipping Dec 30th and going straight to Dec 31st.
How you could program your way out of that, and plan around that as a possibility in scheduling/calendars, is a bit mind bendy. "Turns out this day won't exist for you" is never something I'd have considered a possibility.
One of the early examples taught in high school programming classes is that of finding if a year is a leap year. Usually followed by noting how that change was introduced in most of Europe only in the late 16th century. A whole 10 days have gone missing in a bunch of countries, though everyone transitioned slightly differently. Many Eastern Orthodox countries only transitioned in 19th or 20th century, having 13 days disappear into the void.
There are also leap seconds, so your seconds can go past 59 too.
Calendars are a hard topic because they are tied to local standards so tightly. Let's not forget that not all cultures use the same "solar calendar" today either!
The best approach is to decouple timestamping from locality (eg. only ever store UTC times), and embed locale data (like DST/timezone) only if needed (if you need to show time-of-creation local times for historical data). For everything else, you should interpret for display purposes, but the arithmetic and reasoning become much simpler.
Julian dates (now's JD 2459146.6823) can help even more with that (similar to seconds-since-Unix-epoch we developers are used to, they count days-since-history-began in rational number form), but most time storage does not require stability going that far back, so just storing UTC times should work.
When countries switched from the Julian to the Gregorian calendar this happened everywhere. Entire counties skipping weeks in their calendars. Historical documents referring to the same event but using different dates, because they were using different calendars. Fun times. And of course not every country switched at the same time.
The Wikipedia page about this is pretty interesting [0] Some quotes from that page:
> In Russia, the Gregorian calendar was accepted after the October Revolution. On 24 January 1918 the Council of People's Commissars issued a decree that Wednesday, 31 January 1918, was to be followed by Thursday, 14 February 1918, thus dropping 13 days from the calendar.
> Catholic countries such as the Polish–Lithuanian Commonwealth adopted the "new style" (N.S.) Gregorian calendar in 1582 (switched back in 1795 after Third Partition of Poland)
And if you think that is bad, the Roman calendar that was replaced by the Julian calendar had a year consisting of 304 days and when things got too much misaligned with the seasons some extra days would be added [1]
> The system is usually said to have left the remaining 50 odd days of the year as an unorganized "winter", although Licinius Macer's lost history apparently stated the earliest Roman calendar employed intercalation instead[7][8] and Macrobius claims the 10 month calendar was allowed to shift until the summer and winter months were completely misplaced, at which time additional days belonging to no month were simply inserted into the calendar until it seemed things were restored to their proper place.
Good thing computers weren't around back then.
[0] https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
[1] https://en.wikipedia.org/wiki/Roman_calendar#Legendary_10_mo...
On the other hand, some of them come from not appreciating that a timezone is a cultural and legal construct of a region. Even if it were true that every extant timezone was a multiple of an hour off of utc, it would still be wrong to think that was always going to be the case.
Maybe I'm a fringe case, but even though my company only exists in two timezones this difference still affects me every day on Slack...
Presumably it's not easier because everyone important lives in San Francisco. \s