I think I’ve been around too long. As the developer who had to patch an appliance to deal with timezone changes in both North America (our primary market) and Australia, I believe none of these falsehoods.
One thing I do know. By keeping up with the olsen timezone database, you never need to worry about these edge cases http://web.cs.ucla.edu/~eggert/tz/tz-link.htm
It is mentioned in the article as the Olsen DB is now maintained by IANA, and it still has problem of using city names instead of zone names.
Except the olsen db does use zone names, they’re in the Zone section. They also use geographical locations because zone names can be confusing. Contrary to the article, Australians do occasionally refer to the NSW TZ as EST, and is it AEDT, or AEST? Depends on where you are in the AEST TZ, and what time of year it is.
The fact that time zones can be picked by major cities instead of by their semi-standardized name is a massive UX improvement instead of “basically bad UI that derives from the IANA zone keys”.
I think it is the only somewhat understandable way to do it and combined with location detection also very convenient.
Last year Brazil ignored daylight savings time:
We had an email send out that was split into two job sets, a queuing job that used Postgres’ timezones db to load recipients due and a bunch of send out jobs that actually send the emails that have an application layer failsafe to make sure the email is actually due. We updated the application library before the Postgres instance and so that meant there was a situation one week where our one Brazilian customer would trigger the failsafe, resulting in a pretty confusing error. I was lucky I had a Brazilian engineer on my team who knew about the change!
As the go-to “timezone guy” for our product, nothing in this list is new to me.
I follow RSS feeds from a couple of sources (including Microsoft’s TZ team which does amazing work) and I’m continually surprised by how cavalierly politicians deal with stuff like timezones and DMZ. Recently I learned the Palestinian territory will end DST one week early (in line with the EU changeover). Why was this not the case before? Who knows. Why was this change so sudden? Again, who knows.
Apparently, DST changes in Jordan have to be approved by the king. Not surprisingly, he has a lot of stuff to deal with, so sometimes people there simply don’t know if DST is going to happen at all.
Russia suspending changeover from DST around 6 years ago (essentially creating a bunch of new timezones) led to no end of trouble for users of our product.
The promised EU re-evaluation of DST is apparently on hold, but by biggest nightmare is that it will be pushed through in some late-night session giving users, programmers and TZ info maintainers only days to deal with the change.
I once worked on a system to help city bus planners.
In the most popular transit management software (an ancient text based thing that dates to the early 80s), routes always end on the same date they started. So if a night bus leaves the depot at 22:00 and drives for 8 hours, it’s last stop is simply at 30:00 on the same day. That’s the standard system for the whole industry, and transit planners will even refer to it that way.
Manipulating those time stamps was super fun…
That’s a thing in japan too, see last paragraph of https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japan