The surprising whimsy of the Time Zone Database

> Here Eggert is ostensibly trying to get a sovereign government to participate in the "TZDB's requirements" and since he can't has to invent a hack to make things appear to work. Which is completely backwards and highlights precisely why I think this whole centralized database concept for this problem is flawed.

Eggert is petitioning the government for a redress of greivances on behalf of more or less the entire computing industry (or whatever portion follows POSIX): to whit, the world has come to agreement that timezone abbreviations must match [-+[:alnum:]]{3,6} and PT does not match that.

Now, BC government could ask every vendor of software that displays a time zone abbreviation to use PT, and then they could individually come back and say, no it needs three letters. And then they could threaten to not buy products that won't say PT and not allow imports of said products... But then the vendors would probably ask if they have control over imports or if that's a federal responsibility (I don't know) and that they're not doing a one off to fix something for BC. But if that's how it's going to be, probably maybe come back with POs in 5 years when POSIX standards have filtered down to allow two character abbreviations. Seems easier to get told it's a problem in one place and hopefully figure out what the answer is once.

>he world has come to agreement

No, it hasn't. I commonly use PT myself which doesn't fit that format. It's the timezone that the west coast of America uses which makes it very convenient if you live there instead of having to remember if the day your meeting on is with or without daylight savings. The three timezones we use here are:

PT: The time of the day that all of our clocks are going to be set to.

PST: The time when daylight savings is not active.

PDT: The time when daylight savings is active.

Nice visualizations. I went the opposite way, showing how many times the timezones were adjusted for different regions, on map (both with and without DST).

https://ciju.in/writings/understanding-timezones

Just last night some friends brought up the time change tonight and the news from British Columbia, and what the California government has or hasn't done about it currently and in the past and why we haven't just gotten rid of the system already to save us the trouble of adjusting clocks twice a year.

And of course, there was instantly a heated debate about whether to permanently choose Standard Time or Daylight Saving Time, with passionate, almost religious arguments for both options. I feared sectarian violence was about to erupt at the dinner table.

Our collective relationship with time is truly unhinged.

#teamdaylightsaving

> You need it to encode or decode past dates to unix time or other time standards.

Which you need to do if

> You do not need it to "interpret" past dates.

you want to interpret past dates. Mainly you need a historical record of the offsets. Or you're trading inaccuracy of duration measurement from one or two days out of the year to every day of the year by not keeping track of historical offsets or taking them into consideration.

It is absolutely not esoteric for a user to want to know, for example, an accurate duration measurement between a past departure time in one zone and a past arrival time in another zone. (inb4 the user is supposed to somehow anticipate all possible datetimes and calculate these durations in advance in case they need them)

> Combining these two concerns with insanely different scopes is precisely the issue with the tzdb.

I'm laughing so hard at what I just visualized. "Oh, no you only use this zone library for current times, use this other library for past times".

Then someone gets this crazy idea to use just one library and realizes it's quite ridiculous to need a DNS client to pull in the records when they have this other library that has the historical and current zones in a few text files. So then they drop the DNS client and just start using tzdb. It can even work for future dates and times too!

As soon as you create a timestamp, it becomes a recording that needs to take historical zone information into account when interpreting it.