The amount of effort and detail that goes into this database is astonishing - every few days there's a new twist introduced by timezone legislation somewhere around the world.
Even more impressive is their dedication to building a correct database of historic timezone changes - here's a post where someone submitted further details on the history of time in Macau for example: https://mm.icann.org/pipermail/tz/2018-May/026467.html
It's also a useful reminder to never, ever attempt to do datetime math on your own. Always use a library! And if that library is buggy, submit patches but don't say "aww, I'll just do it myself".
In a statement, Astrolabe said, "Astrolabe's lawsuit against Mr. Olson and Mr. Eggert was based on a flawed understanding of the law. We now recognize that historical facts are no one's property and, accordingly, are withdrawing our Complaint. We deeply regret the disruption that our lawsuit caused for the volunteers who maintain the TZ database, and for Internet users."
Ok, when we consider events prior to the Big freaking Bang as historical, and have test code for it, then I feel we are in safe hands.
Keep up the good work folks :-)
In practice, however, people write bad date/time code often enough that it’s a problem. I was recently using a client library that was completely broken if the client’s system had a negative offset from UTC more than 1 hour.
At work we get emails if we leave any container running that was built too long ago (three months or something?)
Biggest benefit: the timestamps in logfiles are actually correct and make sense.
I wonder if this will break anything. Some systems make the bad assumption that timezone abbreviations are unique, e.g. when parsing dates.
But you should under no circumstances record the offset. Record either a timestamp or local time + location.
But at the last minute, the government announces it's happening on March 4. And your systems haven't yet been updated to reflect this.
So humans move their clocks forward one hour on March 4.
You write somewhere in a text field "March 4 4pm".
"March 4 4pm America/Los_Angeles" doesn't help you, because it's not clear whether you thought "America/Los_Angeles" was -0800 or -0700. And it's not clear whether the system interpreting that date agrees with you.
To be unambiguous, you need to say "March 4 4pm -0700". Otherwise the system might assume the effective timezone is -0800, per the rules it knows. Without unambiguous input, correctly parsing such times is impossible.
You could also use Olson timezones for past events, but then you'd also have to record which version of the timezone rules you were using. And of course nobody does that because it's overcomplicated and unnecessary.
You're right that converting back to 4pm for display is problematic. The simplest solution is to always display UTC. But if you want to convert to the user's preferred timezone, during this time, yes, the system would display 3pm until it got the updated timezone rules. There are more complex solutions, but for most use cases just displaying "March 4 3pm -0800" would be adequate.
What about us in Pacific daylight time? Now our timezone acronym is ambiguous.
Upstream database is here: