The surprising whimsy of the Time Zone Database
muddy.jprs.me
muddy.jprs.me
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 :).
I was curious and found more info here: https://www.computerworld.com/article/1548822/astrolabe-with...
Linked from https://github.com/eggert/tz/blob/main/asia#L3818
I don't think I have anything on my network hammering GH...
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.
But Spain is much further to the west.
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
Don't talk to me or my son ever again.
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.
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.
https://blog.scottlogic.com/2021/09/14/120-years-timezone.ht...
> 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.
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.
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.
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...
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?
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.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.
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.
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.
“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.
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.
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.
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.
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 -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.
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.
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.
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?
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
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.
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)