Item — HN Reader

That would provide the machine readable version... but not the human documentation of time. You wouldn't be able to debug the Moroccan Ramadan rule (which is provided as some elisp code) and its predictions for future changes.

Having it be managed by governments would mean that the whim of a politician could break things by changing the established name... say from "US/Pacific" to "USA/Pacific" or deciding by fiat to change the timezone for a political enclave within another one that doesn't have a TLD. ( https://github.com/eggert/tz/blob/main/northamerica#L821 )

This also describes the compromises in the design of the system to accurately record the time.

    # From Paul Eggert (2026-03-07):
    # The law says that 21 hours after the usual 2026-03-08 02:00 switch from
    # PST to PDT, the next day inaugurates the new standard time Pacific Time,
    # i.e., just one clock change but two name changes separated by 21 hours.
    # PT, the obvious abbreviation for Pacific Time, is one letter too short
    # to conform to TZDB’s (and POSIX’s) [-+[:alnum:]]{3,6} requirements.
    # I asked the BC government for advice, with no response. For now, do this:
    #   1. As a temporary hack, pretend that the BC law takes effect
    # not on 2026-03-09 at 00:00, but on 2026-11-01 at 02:00.
    # This pretense works around a limitation in CLDR v48.1 (2026-01-08),
    # which would otherwise say the interval uses “Pacific Standard Time”.
    # (Below, this temporary hack is marked “Temporary hack; see above.”)
    # Strictly speaking this hack is incorrect since the interval uses
    # standard time, but it does have the right UT offset and it
    # works around the CLDR limitation.  We should be able to remove
    # the temporary hack after CLDR is fixed.

1 comments

> but not the human documentation of time.

And a single database maintained by a volunteer and accountable to no one is the best way to achieve this?

> say from "US/Pacific" to "USA/Pacific"

Did the US assign itself the .us TLD? These things are already defined. A more realistic example would be the US changing the name of the "Pacific" timezone to the "Western" timezone. All users of that timezone have to incorporate that change anyways and most would probably want to.

> change the timezone for a political enclave within another one that doesn't have a TLD.

You could actually grant the entire Navajo Nation the .nsn.us.timezone subdomain. I'm sure they find it absolutely insulting to be instructed to use "America/Denver." Why is that better? We could directly grant them their own authority.

There's also a handful of countries the tzdb didn't bother with and instruct to use their neighboring countries definition. In some instances this arrangement can be rather insulting to the political history of the two countries. Why is this better?

> the compromises in the design

What compromise? 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.

accountable to no one

There's a good lesson here for any who wants to be a founder and start their own company - the maintainers of the timezone DB are accountable to their users, just as any founder is accountable to their customers.

If the timezone DB maintainers start messing around with the way it works, they will quickly find that people start alternatives, which would be worse for everyone. Governments would choose to own them, and the bad things other posters have talked about would happen. Particularly bad governments would pass laws that mandate the IT systems in that country would have to use their timezone data. That would be yet another way a country can exert control. The only reason they don't do it now is because it's incredibly hard work and obviously no value when there's a gold standard available for free.

If you're choosing to start a business you should remember that this is true of your customers - if you start messing with things for the fun of it rather than because it provides obvious value, those customers will go somewhere else.

> 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.

It's very common for conferences and the like to use shorthand like PT or ET. The reality is that once you start specifying standard time or daylight savings time, the people writing the announcement regularly mess up. I don't remember what the house style was at my prior company but I regularly saw people putting EST or EDT at times of the year when it wasn't correct.

This sounds like a classic case of engineers trying to overspecify and demand that things fit their nice little database, reality and life isn’t like that.

“PT” is more correct than many other things you could list, because people always forget which is DST and which is Standard.

It’d probably be cleaner to say that Pacific is on Mountain Time half the year.

Funnily enough, I just got a bunch of one hour computer schedule changes for a European event in late March. I assume this is related to Daylight Savings vs. Standard Time. I'm sure I'll work it out once I'm over there.

The additional complication is that the US and Europe switch on different dates, so they’re “out of sync” one way or another.