The surprising whimsy of the Time Zone Database

Which I would find "cute" if the database contained an equal amount of reason. I am perennially irritated that "US/Pacific" which is an _official_ name of a time zone _as used_ by the relevant time keeping authority, is called "backwards."

I still think we should move away from a tz database, a 1970s idea, and move to a .timezone TLD with tzinfo stored in TXT records. Give each country it's own NS in the TLD and give them the authority to update it. If you still want a "full file" then do a zone transfer. Plus, we could also use punycode, and easily have fully internationalized time zone names, something we currently lack.

I genuinely dislike the structure and nature of the tz database.

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.

That said, I would never respect the DNS TTL of such a scheme, for my own use cases. I'd query each of them once an hour, latch the last response forever, and delay propagation of a new response for a full week that it stayed stable before serving the new record.

The timezone database was not created for the benefit of governments, it was created for the benefit of users and vendors.

People who have to live their lives under corrupt/incompetent governments have enough problems on their plate already, without the added indignity of making it harder for them to get their computers to show the correct local time.