Announcing global-tz - 2022ag (beta)
As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute). As previously discussed, and given the unwillingness of the tz-coordinator to alter his opinion in any way, it is unfortunately the case that a fork of tzdb is required. I have created such a fork, one that is intended to be as directly derivable from iana-tz as possible so that iana-tz itself can still be the golden source for the raw data. https://github.com/JodaOrg/global-tz The basic rules guiding the data that global-tz includes are: * An identifier for each region of the world where clocks have differed since 1970-01-01. * At least one identifier for each inhabited ISO 3166-1 code. * For these identifiers the data returned shall be the best available, including pre-1970 history. The first release of the fork is 2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections. https://github.com/JodaOrg/global-tz/releases/tag/2022ag-beta1 The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*. A GitHub Action script runs a few times a day that reads the iana-tz repo and runs a script that moves data from backzone to the appropriate main file. The result is an iana-tz compatible source code repo: Output tzdb source files: https://github.com/JodaOrg/global-tz/tree/global-tz Comparison between iana-tz and global-tz: https://github.com/JodaOrg/global-tz/compare/iana-tz...global-tz Genaration script: https://github.com/JodaOrg/global-tz/blob/main/actions.txt https://github.com/JodaOrg/global-tz/blob/main/GlobalTzMain.java The only maintenance that the fork should need is if iana-tz removes further pre-1970 history. Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward. Please can I ask anyone that is interested to test out the 2022ag-beta1 release before I make it final. PRs / Issues are welcome, provided they relate to aspects under the control of global-tz. thanks Stephen
On 3/18/22 09:00, Stephen Colebourne via tz wrote:
2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections.
That naming convention would collide with tzdb's already-existing naming convention, if we are unlucky to have 33 or more releases this year. A name like '2022a-g' would avoid any such collision.
My understanding is that tzdb will need to use za, zb, zc after z, because otherwise the versions don't have the correct alphabetical sort order which I believe downstream systems see as an important property of the naming scheme. Is this documented somewhere? I don't see it in theory. I know there is some resistance to names with characters other than a-z, so I wouldn't want to choose -g as a suffix. Thanks Stephen On Fri, 18 Mar 2022, 16:47 Paul Eggert, <eggert@cs.ucla.edu> wrote:
On 3/18/22 09:00, Stephen Colebourne via tz wrote:
2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections.
That naming convention would collide with tzdb's already-existing naming convention, if we are unlucky to have 33 or more releases this year. A name like '2022a-g' would avoid any such collision.
On 3/18/22 11:48, Stephen Colebourne via tz wrote:
My understanding is that tzdb will need to use za, zb, zc after z
Oh, right! My mistake. Still, it'd be better to use a naming scheme that is a bit more distinctive, as others are likely to make similar mistakes and it's better to avoid confusion.
I'm happy to go with "2022agtz" which effectively solves the issue I believe. Stephen On Fri, 18 Mar 2022 at 19:36, Paul Eggert via tz <tz@iana.org> wrote:
On 3/18/22 11:48, Stephen Colebourne via tz wrote:
My understanding is that tzdb will need to use za, zb, zc after z
Oh, right! My mistake.
Still, it'd be better to use a naming scheme that is a bit more distinctive, as others are likely to make similar mistakes and it's better to avoid confusion.
On Fri, 18 Mar 2022 at 14:48, Stephen Colebourne via tz <tz@iana.org> wrote:
My understanding is that tzdb will need to use za, zb, zc after z
There would still be a version-naming conflict at the 33rd release of a year (NNNNzg), it would just be with the 26th release of the downstream project and not the first. -- Tim Parenti
On 3/18/22 12:39, Tim Parenti via tz wrote:
There would still be a version-naming conflict at the 33rd release of a year (NNNNzg), it would just be with the 26th release of the downstream project and not the first.
Oh, good point. So we'll still need some sort of different convention to avoid potential conflicts. I suppose it could be done with a prefix string rather than a postfix.
On 18/03/2022 20:09, Paul Eggert via tz wrote:
On 3/18/22 12:39, Tim Parenti via tz wrote:
There would still be a version-naming conflict at the 33rd release of a year (NNNNzg), it would just be with the 26th release of the downstream project and not the first.
Oh, good point. So we'll still need some sort of different convention to avoid potential conflicts.
I suppose it could be done with a prefix string rather than a postfix.
Or another letter after the g. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
The final release is now available. https://github.com/JodaOrg/global-tz/releases/tag/2022agtz thanks Stephen On Fri, 18 Mar 2022 at 16:00, Stephen Colebourne <scolebourne@joda.org> wrote:
As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute).
As previously discussed, and given the unwillingness of the tz-coordinator to alter his opinion in any way, it is unfortunately the case that a fork of tzdb is required. I have created such a fork, one that is intended to be as directly derivable from iana-tz as possible so that iana-tz itself can still be the golden source for the raw data.
https://github.com/JodaOrg/global-tz
The basic rules guiding the data that global-tz includes are: * An identifier for each region of the world where clocks have differed since 1970-01-01. * At least one identifier for each inhabited ISO 3166-1 code. * For these identifiers the data returned shall be the best available, including pre-1970 history.
The first release of the fork is 2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections.
https://github.com/JodaOrg/global-tz/releases/tag/2022ag-beta1
The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*. A GitHub Action script runs a few times a day that reads the iana-tz repo and runs a script that moves data from backzone to the appropriate main file. The result is an iana-tz compatible source code repo:
Output tzdb source files: https://github.com/JodaOrg/global-tz/tree/global-tz
Comparison between iana-tz and global-tz: https://github.com/JodaOrg/global-tz/compare/iana-tz...global-tz
Genaration script: https://github.com/JodaOrg/global-tz/blob/main/actions.txt https://github.com/JodaOrg/global-tz/blob/main/GlobalTzMain.java
The only maintenance that the fork should need is if iana-tz removes further pre-1970 history.
Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward.
Please can I ask anyone that is interested to test out the 2022ag-beta1 release before I make it final. PRs / Issues are welcome, provided they relate to aspects under the control of global-tz.
thanks Stephen
On 2022-03-19 00:00:54 (+0800), Stephen Colebourne via tz wrote:
As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute).
I have strongly mixed feelings about this fork but I appreciate your efforts in trying to resolve the deadlocked dispute. Thank you. Considering the existence of this fork and the fact that the overwhelming majority of users are not affected by the merging of pre-1970 time zones, my plan is to merge the tzdata 2022a release into supported FreeBSD releases unmodified. I will create a port of your fork which affected/interested users can install, either using the ports framework or as a binary package. Depending on the direction of consensus among other operating system distributions, FreeBSD may change the default zoneinfo source at some point. Given that the most controversial changes in 2021b have been undone in 2021c, I don't see a pressing need to change to global-tz at this time.
The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*.
This is a good approach.
Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward.
The generated global-tz/tzdata omits the zone1970.tab file. I understand that your intended use case has no need for this file but if you distribute it, your tzdata tarball would be a drop-in replacement for the IANA tzdata tarball. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Mon, 21 Mar 2022 at 04:57, Philip Paeps <philip@trouble.is> wrote:
On 2022-03-19 00:00:54 (+0800), Stephen Colebourne via tz wrote:
As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute).
I have strongly mixed feelings about this fork but I appreciate your efforts in trying to resolve the deadlocked dispute. Thank you.
No problems. From my perspective having done this work, it is obvious to me that it would be a lot simpler if the auto-generation was in the other direction. ie. if the main TZDB source files contained all the relevant data (ie. what global-tz has done), and an automated job stripped it down to the minimal data set that the tz-corrdinator desires.
I don't see a pressing need to change to global-tz at this time.
I think we are currently at an unstable equilibrium. The contents of IANA TZDB discriminate against non-European locations, because there are essentially two different rules in operation as to what data is included. global-tz represents one way to solve that issue, by consistently applying one rule globally. The question distributors will need to answer is what they want to do once European pre-1970 history is removed from zones that are merged (as distributors are tacitly accepting the discrimmination of the current unstable equilibrium).
The generated global-tz/tzdata omits the zone1970.tab file. I understand that your intended use case has no need for this file but if you distribute it, your tzdata tarball would be a drop-in replacement for the IANA tzdata tarball.
Hmm. I hadn't intended for the file to be missing from the tar.gz. I only mentioned it in the automated job as it causes "make check" to fail. (PRs welcome!) thanks Stephen
On 2022-03-21 16:31:30 (+0800), Stephen Colebourne via tz wrote:
On Mon, 21 Mar 2022 at 04:57, Philip Paeps <philip@trouble.is> wrote:
On 2022-03-19 00:00:54 (+0800), Stephen Colebourne via tz wrote:
As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute).
I have strongly mixed feelings about this fork but I appreciate your efforts in trying to resolve the deadlocked dispute. Thank you.
No problems. From my perspective having done this work, it is obvious to me that it would be a lot simpler if the auto-generation was in the other direction. ie. if the main TZDB source files contained all the relevant data (ie. what global-tz has done), and an automated job stripped it down to the minimal data set that the tz-corrdinator desires.
I don't see a pressing need to change to global-tz at this time.
I think we are currently at an unstable equilibrium.
I agree but I am trying to keep that discussion out of this thread.
The generated global-tz/tzdata omits the zone1970.tab file. I understand that your intended use case has no need for this file but if you distribute it, your tzdata tarball would be a drop-in replacement for the IANA tzdata tarball.
Hmm. I hadn't intended for the file to be missing from the tar.gz. I only mentioned it in the automated job as it causes "make check" to fail. (PRs welcome!)
Since the tzdb has been encouraging applications to use zone1970.tab in preference to zone.tab since its introduction in 2014, it would be good to include this file. The failure in "make check" is caused by checktab.awk (correctly) failing because zones exist in the data files that are not referenced in zone1970.tab. Unfortunately, simply copying zone.tab to zone1970.tab won't work as the newer format does not support backward links in the third column (e.g. Europe/Mariehamn). The limitation that a comment can only exist if a country has multiple timezones (e.g. Pacific/Pago_Pago) is likely less of a problem. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Date: Mon, 21 Mar 2022 12:57:34 +0800 From: Philip Paeps via tz <tz@iana.org> Message-ID: <7DAA0224-974F-4FAE-9D1E-5F02924BDCC0@trouble.is> | Considering the existence of this fork and the fact that the | overwhelming majority of users are not affected by the merging of | pre-1970 time zones, my plan is to merge the tzdata 2022a release into | supported FreeBSD releases unmodified. For NetBSD I did just the opposite. I had been manually doing these changes (or some of them) since 2021c, I ignored 2021b, and much appreciate the effort that made the 2022a update much easier. I had started the processof merging the 2022a changes into our sources, when I saw the global-tz announcement, so I just ceased that and waited. I have yet to automate the update process to the extent we have for the releases via the iana web site, but I will. NetBSD current is at 2022agtz now, and the stable releases will be when it has had some settling time. kre
participants (7)
-
Ian Abbott -
Michael H Deckers -
Paul Eggert -
Philip Paeps -
Robert Elz -
Stephen Colebourne -
Tim Parenti