alt.hn

3/7/2026 at 6:32:05 PM

The surprising whimsy of the Time Zone Database

 https://muddy.jprs.me/links/2026-03-06-the-surprising-whimsy-of-the-time-zone-database/

by jprs

3/8/2026 at 5:48:27 AM

I once digged into this database out of curiosity and found incredibly detailed research on many edge cases. Like time zones in Germany being temporarily aligned to Moscow during soviet occupancy after World War Two.

One particular commenter stood out to me, so I looked him up because I was interested which kind of people spend so much time correcting timezone information.

Turns out he was an astrologer and wanted his astrology-program to work perfectly correct.

I find it funny that we have to thank astrology for the correct calculations in our banking software :).

by fzeindl

3/8/2026 at 8:52:36 AM

On the other hand, it was also astrologers that made copyright claims on the database and caused it to become unavailable to the world for a short period of time.

by Mountain_Skies

3/8/2026 at 2:15:34 PM

It were not astrologers, it was a company that creates astrology software.. Don't mix people with companies, they are different things! One is there definitely for the money, the other may or may not..

by jventura

3/8/2026 at 6:16:08 AM

Amusing story of the chaos of timezones in Saudi Arabia and a man who made his own: https://archive.aramcoworld.com/issue/196902/dinner.at.when....

Linked from https://github.com/eggert/tz/blob/main/asia#L3818

by netsharc

3/8/2026 at 8:40:11 AM

I enjoyed getting an instant rate limit screen trying to load that blob (and then the one linked from TFA).

I don't think I have anything on my network hammering GH...

by rawling

3/8/2026 at 4:59:17 PM

Generally, if you're web browser isn't leaking loads of personally identifiable information, everything reacts like you're a bot.

by dlcarrier

3/8/2026 at 2:50:29 PM

I also get that screen on GitHub occasionally, so it's not just you.

by Cyphase

3/8/2026 at 1:32:53 AM

If you like this there has been a interesting discussion on the tzdb mailing list about how to handle the Vancouver change and the next releases of the tzdb and the Unicode Common Locale Data Repository: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/IE...

by dfc

3/8/2026 at 5:42:08 AM

Interesting to see mention of how quickly this was implemented. It seemed sudden to me but I wasn’t sure if I was just out of the loop.

by mulmen

3/8/2026 at 10:24:58 AM

> I’ve perused the tz repository before, and I always learn something interesting. For example, during WWII Britain adopted double summer time, adding two hours to the clock in the summer and one hour in the winter.

My country, Spain, did the same but never fixed it, so we are still in this "double summer time". It is one of the main reasons why Spanish people seemingly do everything later (breakfast, lunch, dinner) than other European countries.

by pezezin

3/8/2026 at 10:55:08 AM

Other Western European countries like France also switched to German time during the war and kept it afterwards.

by kgwgk

3/8/2026 at 1:28:30 PM

Yes, the Netherlands too (we were on +0:20 before).

But Spain is much further to the west.

by Scarblac

3/8/2026 at 4:10:29 PM

Spain is not “double summer time”, it is just on an offset that is off by one hour related to its geographical position.

by grodriguez100

3/8/2026 at 9:43:32 PM

That's why I wrote it in quotes, it is not an official term. But call it however you want, the results are the same.

by pezezin

3/8/2026 at 11:31:05 AM

It's well worth subscribing to the tz updates mailing list, not just to be cognisant of timezone changes, but to add a bit of bemusement to your day.

by liampulles

3/8/2026 at 5:24:43 AM

Is this article finished? There are mentions of excerpts from the database, but the excerpts are not reproduced or linked to, as far as I can tell.

by NewJazz

3/8/2026 at 5:39:37 AM

There is a link to the North America file, where all those referenced stories can be found.

by robotmlg

3/8/2026 at 3:45:37 PM

Got it, didn't realize they were all in the same file I guess.

by NewJazz

3/8/2026 at 11:34:47 AM

Below the link to the North America file, you should see a few examples:

> A spirited attack on daylight savings from Canadian intellectual Roberton Davies in 1947: [full quote]

> A story of a public clock in Nashville in the 1950s with “dueling faces”—one time for conservatives and another for liberals.

> An account of the “day of two noons” in New York City in 1883, when standardized time zones were adopted and “local time” was abandoned forever.

> A detective story about ascertaining the proper chronology of time zones in Resolute Bay, a tiny community north of the Arctic circle.

by jprs

3/8/2026 at 7:49:00 AM

The comment actually has it backwards. It says BC is moving from daylight to standard time, but should be the opposite. It's got the offset right though.

by tempestn

3/8/2026 at 11:35:53 AM

Hmm the comment was a bit difficult to parse, but I think they got it correct. Remember that we have arbitrarily defined the time during local winter as the "standard" time. If we want to keep to that then "permanent daylight savings" is a contradictory term. So what is actually meant is abolishing DST while at the same time changing the standard time to be at the offset of DST before the change. So what I think they are saying is that DST is being abolished, but the actual effective offset at the time when it's abolished is unchanged.

by poizan42

3/8/2026 at 1:06:17 PM

That semantic confusion between daylight saving the switch, and daylight saving the offset, makes it perpetually confusing to argue about whether we should preserve daylight saving at all.

by macintux

3/8/2026 at 1:31:57 PM

As far as the timezone file is concerned, it's two changes but one shift. This is covered more fully in the complete news blob rather than the snippet shown at the top. Today, British Columbia moved from Pacific Standard Time (UTC-8) to Pacific Daylight Time (UTC-7); tomorrow the timezone is renamed to Pacific Time.

Unfortunately, the "PT" abbreviation is too short for the timezone database, so while they decide on another form they will temporarily use a bare -7 offset.

by Majromax

3/8/2026 at 9:16:09 PM

Ah, I see. They're reclassifying it as standard time without changing the offset. Yeah, it was my misunderstanding.

by tempestn

3/8/2026 at 7:32:41 AM

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

by russellbeattie

3/8/2026 at 11:21:08 AM

What is "team DST"? Those who want permanent DST or those who want to do things as they are where DST is on for half of the year?

by ithkuil

3/8/2026 at 1:39:00 PM

The first one, though it's just a joke. I think honestly I'm more #TeamJustPickOneAlready.

by russellbeattie

3/8/2026 at 8:31:01 AM

The thing is, it doesn't matter. Everyone with an argument is wrong. All you're arguing about is when you start/finish work/school. But it it doesn't matter and you have to arbitrarily label the hours of the day with numbers, you'd obviously pick standard time and not randomly offset everything by an hour.

by globular-toast

3/8/2026 at 11:49:45 AM

> you'd obviously pick standard time and not randomly offset everything by an hour

Isn't Pacific Daylight Time = Mountain Standard Time?

You can offset everything by an hour and still have 'standard' in the name of the timezone.

by michaelt

3/8/2026 at 7:13:20 PM

Yeah, you could just start counting from two and call it the standard counting system, but why would you? The current system works fine and there's no need to change it.

by globular-toast

3/8/2026 at 9:07:20 AM

Agreed.

The problem is that so much of our culture is tied to specific hours on the clock (e.g. "9 to 5"), even though it doesn't need to be that way. China has one time zone and it works fine. Most of Spain is west of Greenwich, yet remains on European time. People there just adjust and don't insist that certain times of day have universal meanings.

Standard Time vs Daylight Saving Time is exactly the same as Big Endian vs Little Endian. Jonathan Swift is laughing at us from the beyond.

by russellbeattie

3/8/2026 at 11:56:00 AM

I can say that it will take surprisingly little time for everyone to adjust for any new times. And often the times are already very fluid. Flexible work hours with set core hours are common enough in some places.

by Ekaros

3/8/2026 at 10:12:03 PM

So why change it?

by globular-toast

3/8/2026 at 8:51:08 AM

Though I'd prefer solar noon to be close to clock noon, I'd be fine with permanent DST if it meant we stop fiddling with the clocks twice a year. I can adjust the relationship between clock time and solar time for myself just fine, even if some aspects of society care more about clock time than solar time. It's the hour jump twice a year that annoys me.

by Mountain_Skies

3/8/2026 at 7:56:24 AM

> #teamdaylightsaving

Don't talk to me or my son ever again.

by pinkmuffinere

3/8/2026 at 1:41:38 PM

LOL. I always enjoy a nice meme callback.

by russellbeattie

3/8/2026 at 12:05:36 AM

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

by themafia

3/8/2026 at 1:06:42 AM

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.

by shagie

3/8/2026 at 5:32:04 AM

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

by themafia

3/8/2026 at 7:31:46 AM

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.

by onion2k

3/8/2026 at 5:52:43 AM

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

by toast0

3/8/2026 at 6:17:16 AM

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

by charcircuit

3/8/2026 at 11:16:22 AM

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.

by ghaff

3/8/2026 at 5:38:00 PM

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.

by bombcar

3/8/2026 at 7:38:55 PM

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.

by ghaff

3/9/2026 at 2:44:47 AM

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

by bombcar

3/9/2026 at 6:19:08 PM

Totally. You have the local time at the time of the event, you have current US time, and you have current European time. Yes, computers can handle a lot of this but a lot of people are working off the local times for the event--and I've had a ton of schedule corrections that I've had to confirm.

by ghaff

3/8/2026 at 9:24:25 AM

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)

by somat

3/8/2026 at 8:13:15 PM

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

by synotna

3/8/2026 at 12:47:46 AM

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

by MadnessASAP

3/8/2026 at 5:44:48 AM

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

by themafia

3/8/2026 at 1:24:50 AM

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

by rendaw

3/8/2026 at 5:35:07 AM

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.

by themafia

3/8/2026 at 7:49:32 AM

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

by dqv

3/8/2026 at 4:45:42 PM

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

by shagie

3/8/2026 at 3:18:23 AM

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

by skissane

3/8/2026 at 3:39:02 AM

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.

by GauntletWizard

3/8/2026 at 4:28:54 AM

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

by skissane

3/8/2026 at 4:43:46 AM

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?

by shagie

3/8/2026 at 4:38:59 AM

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

by phantomathkg

3/8/2026 at 8:08:56 AM

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.

by Freak_NL

3/8/2026 at 4:22:13 AM

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

by wolrah

3/8/2026 at 5:03:47 AM

There once was a country named Czechoslovakia.

by vincent-manis

3/9/2026 at 2:56:57 PM

Manu countries have multiple TZ

by iberator