backward file for zonenow.tab?
Hi. Our software tries to expose a list of supported timezones to an end user for setting up some periodic scheduled task in the UI. Till now we've tried to populate the list of Java supported timezones, filtering out aliases (from backward file). I noticed that zonedata now ships with zonenow.tab file which is exactly what we need for our UI and meets our needs more precisely. Unfortunately it seems quite impossible to migrate old data to this new notation automatically. For example, hte fact that 'Europe/Berlin' is covered by 'Europe/Paris' in zonenow.tab is not mentioned anywhere. Is there a way to determine this fact from tzdata without deep analysis of the rules done by myself? Other simple question: is there a way to know what is "now" in zonenow? Is it defined by the release date of a new version?
On 2025-11-14 08:48, kirill.gagarski--- via tz wrote:
I noticed that zonedata now ships with zonenow.tab file which is exactly what we need for our UI and meets our needs more precisely.
Unfortunately it seems quite impossible to migrate old data to this new notation automatically. For example, hte fact that 'Europe/Berlin' is covered by 'Europe/Paris' in zonenow.tab is not mentioned anywhere. Is there a way to determine this fact from tzdata without deep analysis of the rules done by myself?
checknow.awk already does that analysis. The attached proposed patch causes it to put the zone equivalence class information into now.ck, if you run the command 'make now.ck'. I'm attaching the resulting now.ck that I just built that way. This is all a bit of a hack, but it was easy for me to add and I hope it serves your purpose.
Other simple question: is there a way to know what is "now" in zonenow? Is it defined by the release date of a new version?
That's the intent, yes. By default, "now" is when you run "make now.ck", which is run as part of the release check process (see "make public"). I suppose in theory this value of "now" could be far enough from the release timestamp that zonenow.tab could be wrong for the release timestamp, but this is so unlikely that I haven't worried about it: the timestamps differ by at most a few minutes in practice, and if zonenow.tab would mutate that soon in the future - something that has never happened - I'd likely just wait a few minutes before releasing. You can specify "now" by running "make CHECK_NOW_TIMESTAMP=$N now.ck", where $N is the number of seconds since 1970, not counting leap seconds. The now.ck file's first column specifies the value of "now" that was used to build now.ck.
checknow.awk already does that analysis. The attached proposed patch causes it to put the zone equivalence class information into now.ck, if you run the command 'make now.ck'. I'm attaching the resulting now.ck that I just built that way. This is all a bit of a hack, but it was easy for me to add and I hope it serves your purpose.
Any chance that the patch and resulting artifact will be included in future tzdata updates?
I hope it serves your purpose.
It does not directly, but I can work with it. I guess I'll need to extract "main guy" for the equivalence class from the zonenow.tab file. Though, if it's generated automatically, is there a "main guy" in the class? Or being "main" (the one present in zonenow.tab) is defined by it being first in the source? Sorry for multiple posts, didn't figure out that previous ones were pre-moderated. On Fri, Nov 14, 2025 at 7:18 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2025-11-14 08:48, kirill.gagarski--- via tz wrote:
I noticed that zonedata now ships with zonenow.tab file which is exactly what we need for our UI and meets our needs more precisely.
Unfortunately it seems quite impossible to migrate old data to this new notation automatically. For example, hte fact that 'Europe/Berlin' is covered by 'Europe/Paris' in zonenow.tab is not mentioned anywhere. Is there a way to determine this fact from tzdata without deep analysis of the rules done by myself?
checknow.awk already does that analysis. The attached proposed patch causes it to put the zone equivalence class information into now.ck, if you run the command 'make now.ck'. I'm attaching the resulting now.ck that I just built that way. This is all a bit of a hack, but it was easy for me to add and I hope it serves your purpose.
Other simple question: is there a way to know what is "now" in zonenow? Is it defined by the release date of a new version?
That's the intent, yes. By default, "now" is when you run "make now.ck", which is run as part of the release check process (see "make public"). I suppose in theory this value of "now" could be far enough from the release timestamp that zonenow.tab could be wrong for the release timestamp, but this is so unlikely that I haven't worried about it: the timestamps differ by at most a few minutes in practice, and if zonenow.tab would mutate that soon in the future - something that has never happened - I'd likely just wait a few minutes before releasing.
You can specify "now" by running "make CHECK_NOW_TIMESTAMP=$N now.ck", where $N is the number of seconds since 1970, not counting leap seconds. The now.ck file's first column specifies the value of "now" that was used to build now.ck.
On 2025-11-14 10:44, Kirill Gagarski wrote:
Any chance that the patch and resulting artifact will be included in future tzdata updates?
The proposal is to include the patch, but not the artifact. You can generate the artifact by running 'make now.ck' on any standard platform.
I guess I'll need to extract "main guy" for the equivalence class from the zonenow.tab file. Though, if it's generated automatically, is there a "main guy" in the class? Or being "main" (the one present in zonenow.tab) is defined by it being first in the source?
You can see the answers to those questions by looking in now.ck. For example, the zonenow.tab entry Europe/Berlin is in the now.ck equivalence class "Africa/Ceuta ... Europe/Berlin ... Europe/Luxembourg" containing 34 zones. There is no particular order to class members.
I tried to play around with your patch. It generates the desired file indeed. I though, as far as I am running build scripts, I can try to generate "compromise" .tab file, like for 5-10 years history. But apparently this is not the case and zonenow.tab is manually crafted and now.ck just checks its correctness. Please tell me if I am wrong.
You can see the answers to those questions by looking in now.ck.
Yes, I can see that all members of equivalence class in now.ck are equal, however, I can detect main one by the presence in zonenow.tab file.
The proposal is to include the patch, but not the artifact.
This kind of artifact may be useful in general. Besides "migrating from 1970 to now" case, it may serve purpose of "normalization-to-now" of "1970-timezone" coming from external source, e. g. user browser. Maybe some format more friendly than equivalence classes will be more convenient (close to generated Link-table, like we have in backward file). In general zonenow.tab covers a very common use case indeed, but it's harder to use without mapping from 1970-based timezones. So maybe you can consider shipping this kind of artifact as well.
On 2025-11-14 15:30, Kirill Gagarski via tz wrote:
zonenow.tab is manually crafted and now.ck just checks its correctness
That's correct. I don't see a plausible way to generate a zonenow.tab file automatically from the other files given. If I had seen a way to do it I would have done it that way, to simplify future maintenance. More generally, I don't see a plausible way to generate a zoneT.tab file for an arbitrary time T. You could ask generative AI to do it, but it'd probably do it incorrectly. One more thing. You can't in general use an older zonenow.tab to process today's data, as there may be a zone in today's data that didn't exist back when the older zonenow.tab file was released. As it happens, that has never occurred since zonenow.tab was first released in 2023d; but it may happen in the future.
I hope it serves your purpose.
It does not directly, but I can work with it. I guess I'll need to extract "main guy" for the equivalence class from the zonenow.tab file. Though, if it's generated automatically, is there a "main guy" in the class? Or being "main" (the one present in zonenow.tab) is defined by it being first in the source?
I am afraid there is no concept of "main guy" there. I raised a similar issue in this list recently. My constraints were a bit different (I wanted to have at least one distinct zone per country) but I also needed a way to find out which was the "main" zone, given a set of zones that have equivalent behaviour if historic data is not relevant. You can have a look at that thread in the list archives (https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/RDI2IRJBQZWQHKVPLJ...). The result of that discussion was that a reasonable approach would be to sort each set of equivalent time zones by population, and take the one with the most population as the "main one" in the group. This was useful advice, but I am not 100% convinced this is the way I want to go, so I am still investigating options. Best regards, Guillermo Rodriguez Garcia guille.rodriguez@gmail.com
participants (4)
-
Guillermo Rodriguez Garcia -
Kirill Gagarski -
kirill.gagarski＠gmail.com
-
Paul Eggert