[themafia]

> the Time Zone Database also contains a surprising amount of whimsy.

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.

[shagie]

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.

[themafia]

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

[onion2k]

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.

[toast0]

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

[charcircuit]

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

[ghaff]

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.

[bombcar]

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.

[somat]

On the subject of "Things that should be in DNS" the public suffix list. Why on earth is data describing DNS trust boundaries not in the DNS? It's bizarre.

https://publicsuffix.org/

So here is my RFC to correct this deficit.

No public suffix records: suffixes are considered private trust them like you trust this domain. (I would like to invert this to suffixes default public and you mark them private but that conflicts with current practice)

TXT record 'v=PS1' suffixes under domain are considered public, treat as a trust boundary.

TXT record 'v=PS2 domain-fragment domain-fragment ...' suffixes under domain are considered public except for listed subdomains, those are private and under our control

and then let the ietf fight for a few years on why this does not work and how we need a huge recursive mess (cough SPF)

[synotna]

For dmarc purposes it is moving to DNS, with dmarcbis the psd tag and treewalk will replace hoping everybody uses the same file and keeps it up to date

[skissane]

> Give each country it's own NS in the TLD and give them the authority to update it

There are 193 UN member states. Then add to that the Vatican, Taiwan, and dozens of overseas (or otherwise special) territories having ISO 3166 country codes. Can you trust all those governments to reliably play their part in such a system?

This is part of why the current setup works - it isn’t dependent on the cooperation of any government agency to function.

[GauntletWizard]

Who cares if it works in places that won't play nice? They're digging their own grave if they don't publish, and only hurting themselves. The nice thing about massively distributed systems is that they can be as reliable as the people who depend on them need them to be, with the relevant authorities having the option to be as real or as clowny as they want to be.

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.

[skissane]

> Who cares if it works in places that won't play nice? They're digging their own grave if they don't publish, and only hurting themselves.

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.

[shagie]

Who maintains what time it was in Yugoslavia in 1970? Or Serbia? What country maintains the time information for the island of Taiwan? Or Hong Kong while under British rule or while under Japanese rule?

It might be possible to use that for the information of now - to answer the question of "what is local time for me based on UTC?" or "what is local time for someone else now?" ... but what about the information of yesterday? When it was 12:01 PM in Chicago in 1948, what time was it in Hong Kong?

[phantomathkg]

You would care if you want to track the hostile countries local time.

[MadnessASAP]

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

This assumes that every point on earth has exactly 1 governing body and that a significant majority of the people agree on who that governing body is and that the governing body gives a rats ass about what time it is. Or that everyone in a region agrees on what time it is. Or that ccTLDs are sufficient to unambiguously cover the entire earths surface.

The time zone database isnt just a record of "official" decisions regarding time, it is a record of what time a population thinks it is. There are geographic overlaps, cultural overlaps, pants on head stupid overlaps. It exists to try and translate between somebody somewhere some when giving a time and date reference to any point in history to whatever time system the user may choose to believe in.

Your solution is insufficiently complex to solve a problem of this complexity.

https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

[themafia]

> Or that everyone in a region agrees on what time it is.

And how does the existence of the tzdb solve this problem in any way?

> Or that ccTLDs are sufficient to unambiguously cover the entire earths surface.

The user can still pick whatever they want. Just as they can now. The user can resolve ambiguity for themselves. Unless the tzdb decides unilaterally that their politically organized name for their timezone is somehow "wrong" and must be moved to the "backwards" file to be removed entirely. In which case they must accept whatever ambiguity the tzdb has created for them. "US/Pacific" is unambiguous. "America/Los_Angeles" is not.

> Your solution is insufficiently complex to solve a problem of this complexity.

You need to solve one problem. Publishing official tz information. If you have extended needs, then by all means, it's a computer, do whatever you like, but for the overwhelming majority of the population of earth, they need one function.

"What time does my government think it is because that time controls when things open, when I'm late for work, and when official paperwork has to be filed."

If you want a "whimsical" database that correctly gets timezones right for certain Japanese islands during the war, then you have that, but honestly, what general use case is there for this?

[rendaw]

You need historic timezone information to interpret past dates, not just the current timezones.

[themafia]

You need it to encode or decode past dates to unix time or other time standards. You do not need it to "interpret" past dates.

Even then the tzdb only covers _offsets_ within a day. So even without it you can get an answer that is very close to the "correct" answer. For dates at that great of a remove the lack of accuracy to a precise second is rarely a problem.

I don't exactly need to schedule a remote video phone call with someone still using Double British Summer War Time. For those that do have this requirement they can use whatever specialty database they want.

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

[dqv]

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

[shagie]

> It can even work for future dates and times too!

Morocco has some complex logic around Ramadan... which is a moveable festival.

https://github.com/eggert/tz/blob/main/africa#L854

    Rule Morocco 2026 only - Feb 15  3:00 -1:00 -
    Rule Morocco 2026 only - Mar 22  2:00 0 -
    Rule Morocco 2027 only - Feb  7  3:00 -1:00 -
    Rule Morocco 2027 only - Mar 14  2:00 0 -
    Rule Morocco 2028 only - Jan 23  3:00 -1:00 -
    Rule Morocco 2028 only - Mar  5  2:00 0 -
    Rule Morocco 2029 only - Jan 14  3:00 -1:00 -
    Rule Morocco 2029 only - Feb 18  2:00 0 -

[dqv]

Didn't know that it was moveable! It's actually a great example of why storing future datetimes in UTC is wrong. Future dates should always be stored in local time with appropriate zone information and then converted close to the "decision time". Otherwise, it may represent the wrong local time by the time the dated information is supposed to take effect!

[shagie]

Ramadan really moves around the calendar. From what I understand, summertime Ramadan can be quite challenging to fast from sunrise to sunset. https://www.bibalex.org/SCIplanet/en/Article/Details.aspx?id...

That's part of the reason that Morocco does a time shift during Ramadan - moving sunrise an hour later in the day so that there is more time before dawn to have breakfast. It's daylight savings but for the purpose of more pre-dawn time than afternoon-sun time.

https://www.moroccoworldnews.com/2026/02/278108/morocco-to-r...

> Rabat – The Ministry of Digital Transition has announced that Morocco will suspend daylight saving time and return to GMT on Sunday, February 15 at 3 a.m for Ramadan 2026.

> Astronomical calculations expect Ramadan to begin on February 19 in Morocco. The Ministry of Islamic Affairs will confirm the official starting date after the sighting of the crescent moon.

> Morocco suspends daylight saving time exclusively for the holy month of Ramadan, as it affects the fasting time.

> The ministry emphasized that 60 minutes will be added to the official time at 2 a.m. on Sunday, March 22, following Ramadan.

> ...

> The North African country decided to adopt the daylight saving measure in 2008 during the summer season. The decision’s goal is to increase competitiveness of the national economy through reducing energy consumption and also the time difference between the country and its regional and international trading partners.

> Under the measure, Morocco switched the clock every summer to DST, GMT+1, and returned to the old standard time, GMT, for a period when Ramadan fell in the summer.

> In October 2018, however, the Moroccan government adopted Draft Decree 2.18.855, adding 60 minutes to the standard time in the country year-round.

> The decision stirred controversy and frustration, with Moroccans protesting the move. But it has since become a normal part of Morocco’s preparation for Ramadan.

[Freak_NL]

You do touch upon something which causes a lot of confusion when people start messing with timezones. For tz database a name like 'US/Pacific' is just a label which points to a current and historical set of rules, but for actual people that is the name of their timezone. I tend to look at tz database's file structure as internal logic, and don't take where such labels are stored as having anything to do with what people should call a timezone.

In Europe the Dutch would configure their computers and servers with 'Europe/Amsterdam', but that name is in 'backwards' and it links to 'Europe/Brussels' because Belgium and the Netherlands have had the same timezone rules since 1970 at least. So, should you configure a computer in the Netherlands with 'Europe/Brussels'? Of course not. You, or your operating system, chooses 'Europe/Amsterdam', and if the Dutch government for whatever reason starts to offset their clock by a further 10 minutes then everything will just work.

That won't happen of course, and that raises the topic of standard time. For most Dutch, 'Europe/Amsterdam' is not something they deal with or see when dealing with timezones in real life (unless you are in IT). Instead, they deal with Central European Time (CET) and Central European Summer Time (CEST). Those are in tz database too, and they point to… 'Europe/Paris'. Again, that does not mean 'Europe/Paris' is the canonical name of this timezone which includes more regions than just metropolitan France; it just means that within tz database 'Europe/Paris' was chosen as the label for a large block of (parts of) countries where the same rules are presently observed.

People who take the place of such labels within tz database as prescriptive for what you should call the timezone or standard time they are presently in, are sorely mistaken and risk alienating people. Any piece of software which uses tz database and which claims 'US/Pacific' is a deprecated name is simply broken. Tz database does not mandate that kind of misuse.

> Give each country it's own NS in the TLD and give them the authority to update it.

Oh no. That will lead to a lot of broken things. Let's leave this one topic to this one hyper specific and competent project. Let countries make laws, and have tz database interpret and integrate them. That interface seems to work quite well.

[wolrah]

That might work for the current form of the country-specific time zones officially acknowledged by countries that exist in TLD form, but the tz database contains many more current time zones more importantly piles of historical time zones. Representing just the historical forms of currently recognized time zones in DNS would be a mess, without even getting in to those that are not associated with a country that currently exists and has a TLD.

edit: This is a great video explaining a lot of the reasons why time zones are nowhere close to as straightforward as you may think: https://www.youtube.com/watch?v=-5wpm-gesOY

[vincent-manis]

There once was a country named Czechoslovakia.

[iberator]

Manu countries have multiple TZ