4 ms·

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

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

MadnessASAP 8mo 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. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
- themafia 8mo ago
  > 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?
shagie 8mo 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 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 8mo 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.
rendaw 8mo ago
You need historic timezone information to interpret past dates, not just the current timezones.
- themafia 8mo 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 8mo 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.
skissane 8mo 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 8mo 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 8mo 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.
  - phantomathkg 8mo ago
    You would care if you want to track the hostile countries local time.
  - shagie 8mo 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?
wolrah 8mo 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 https://www.youtube.com/watch?v=-5wpm-gesOY
- vincent-manis 8mo ago
  There once was a country named Czechoslovakia.
Freak_NL 8mo 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.
somat 8mo 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. https://publicsuffix.org/ 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 8mo ago
  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
iberator 8mo ago
Manu countries have multiple TZ

MadnessASAP 8mo 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. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

themafia 8mo ago
> 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?

shagie 8mo 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 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 8mo 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.

rendaw 8mo ago

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

themafia 8mo 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 8mo 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.

skissane 8mo 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 8mo 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 8mo 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.
- phantomathkg 8mo ago
  You would care if you want to track the hostile countries local time.
- shagie 8mo 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?

wolrah 8mo 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 https://www.youtube.com/watch?v=-5wpm-gesOY

vincent-manis 8mo ago
There once was a country named Czechoslovakia.

Freak_NL 8mo 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.

somat 8mo 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. https://publicsuffix.org/ 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 8mo ago
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

iberator 8mo ago

Manu countries have multiple TZ