Rendered at 09:54:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
7 minutes ago [-]
fzeindl 4 hours ago [-]
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 :).
Mountain_Skies 1 hours ago [-]
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.
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...
dfc 8 hours ago [-]
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...
mulmen 4 hours ago [-]
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.
ColinEberhardt 3 hours ago [-]
I agree, timelines are fascinating. I did my own research and built a simple visualisation of the changes in time zones over a 120 year period:
Nice visualizations. I went the opposite way, showing how many times the timezones were adjusted for different regions, on map (both with and without DST).
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.
NewJazz 4 hours ago [-]
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.
robotmlg 4 hours ago [-]
There is a link to the North America file, where all those referenced stories can be found.
russellbeattie 2 hours ago [-]
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
pinkmuffinere 2 hours ago [-]
> #teamdaylightsaving
Don't talk to me or my son ever again.
globular-toast 1 hours ago [-]
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.
russellbeattie 47 minutes ago [-]
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.
1 hours ago [-]
Mountain_Skies 1 hours ago [-]
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.
themafia 10 hours ago [-]
> 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 9 hours ago [-]
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 4 hours ago [-]
> 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 2 hours ago [-]
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 4 hours ago [-]
> 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 4 hours ago [-]
>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.
somat 30 minutes ago [-]
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.
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)
Freak_NL 2 hours ago [-]
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.
MadnessASAP 9 hours ago [-]
> 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.
> 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?
skissane 7 hours ago [-]
> 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 6 hours ago [-]
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 5 hours ago [-]
> 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 5 hours ago [-]
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 5 hours ago [-]
You would care if you want to track the hostile countries local time.
rendaw 8 hours ago [-]
You need historic timezone information to interpret past dates, not just the current timezones.
themafia 4 hours ago [-]
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 2 hours ago [-]
> 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.
wolrah 6 hours ago [-]
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
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 :).
Linked from https://github.com/eggert/tz/blob/main/asia#L3818
I don't think I have anything on my network hammering GH...
https://blog.scottlogic.com/2021/09/14/120-years-timezone.ht...
https://ciju.in/writings/understanding-timezones
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.
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.
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.
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.
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.
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)
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.
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?
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?
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.
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