Should all IDs from backzone be available in backward?
The set of IDs (zones and links) in backzone is _almost_ a subset of the IDs in backward; the only ID that is in backzone but not in backward is Asia/Hanoi. Can Asia/Hanoi be added as a link in backward to ensure compatibility with systems that use IDs from backzone? Is this a desirable invariant that can be upheld in the future? This was reported to CLDR (https://unicode-org.atlassian.net/browse/CLDR-11977), so it looks like there are systems that are using these IDs.
On 2025-06-23 02:51, robertbastian--- via tz wrote:
Can Asia/Hanoi be added as a link in backward to ensure compatibility
No, because 'backward' is intended to be backward compatibility with older names in the primary files, not for compatibility with something else. I see the confusion there, though. Perhaps we should move Asia/Hanoi to a new file named something like "addzone", for those who want to add extra zones not needed for any kind of compatibility with older tzdata.
not for compatibility with something else.
Well, the something else is the TZDB, which can unfortunately be built in many different ways. The problem is that someone *will* build it with Asia/Hanoi, regardless of which file it lives in. Adding it to backward for compatibility is not a big cost.
I agree with Robert. All ID's in backzone need to be in some regular file. The simplest and most compatible way to do that is to put it into backward, and then simply add to the documentation that backward also contains some other IDs from backzone. One could make a separate file 'addzone', but for some period of time implementations will fail to look at that file, leading to continued incompatibilities. So the better choice is just to broaden the scope of 'backward' slightly.
I agree with Robert and Mark: adding a new file seems like it adds unnecessary complexity and will invite incompatibility with some clients. Is there any downside (other than the work required to patch it) to putting this ID into `backward`? Would doing so cause a different incompatibility? Thanks, Justin Grant (I'm the "timezone guy" on TC39, the standards committee for JavaScript) On Tue, Jul 1, 2025 at 3:41 PM Mark Davis via tz <tz@iana.org> wrote:
I agree with Robert. All ID's in backzone need to be in some regular file. The simplest and most compatible way to do that is to put it into backward, and then simply add to the documentation that backward also contains some other IDs from backzone.
One could make a separate file 'addzone', but for some period of time implementations will fail to look at that file, leading to continued incompatibilities. So the better choice is just to broaden the scope of 'backward' slightly.
On 2025-07-01 15:54, Justin Grant via tz wrote:
Is there any downside (other than the work required to patch it) to putting this ID into `backward`?
Yes, it's not what "backzone" was intended for, and continuing down this path will lead to further grief in the future. The original intent of "backzone" was to contain additional data, not part of the main database, with the idea that the file could grow in the future and be maintained in a less centralized way. However, nobody stepped up to add to or maintain "backzone", and in practice it has turned into something different: it is now primarily a way of supporting two versions of tzdb, the default one (which attempts to avoid politics as much as possible) and the backzone one (which instead attempts to avoid changes from older versions of the database). The right way to move forward here is to decouple the two ideas of having extra data vs having old data. Trying to merge the ideas into one file is a recipe for complication, confusion and more political disputes in the future. We should avoid that, as political disputes are the greatest hazard this volunteer project faces.
On Wed, 2 Jul 2025 at 05:21, Paul Eggert via tz <tz@iana.org> wrote:
in practice it has turned into something different: it is now primarily a way of supporting two versions of tzdb, the default one (which attempts to avoid politics as much as possible) and the backzone one (which instead attempts to avoid changes from older versions of the database).
As a reminder to everyone interested, it doesn't have to be this way. The "avoid politics" data is a subset of the "avoid changes" data. It would be a hell of a lot easier to model it that way (ie. with the source data being *all* the available data). Stephen
On 02/07/2025 05:20, Paul Eggert via tz wrote:
The right way to move forward here is to decouple the two ideas of having extra data vs having old data. Trying to merge the ideas into one file is a recipe for complication, confusion and more political disputes in the future. We should avoid that, as political disputes are the greatest hazard this volunteer project faces.
The main niggle here is that backzone does contain verified and accurate data prior to the 1970 cut off, and there is no way to access that data other than using backzone? Handling genealogical and historic data without access to a reliable published source of the pre-1970's data is something of a problem. Something that I had hoped an historic tzdist source might provide but does not seem now to be likely to appear? -- Lester Caine ------------ https://myhomecloud.uk
On 2025-07-02 07:24, Lester Caine wrote:
The main niggle here is that backzone does contain verified and accurate data prior to the 1970 cut off, and there is no way to access that data other than using backzone?
I'm not suggesting removing that data (not all of which is verified and accurate!), only where the data would be.
participants (6)
-
Justin Grant -
Lester Caine -
mark＠unicode.org -
Paul Eggert -
robertbastian＠unicode.org -
Stephen Colebourne