[tz] zdump with version 1 files

[Arthur David Olson]

https://tools.ietf.org/html/rfc8536#section-3.1 gets it right.

A visit to...
    https://ftp.iana.org/tz/releases/
...and a bit of spelunking indicates that as of tzcode2006a.tar.gz, zic was
producing "TZif\0" files and as of tzcode2006c.tar.gz it was producing
"TZif2" files (with both 64-bit data and a TZ string at the end), so it was
a direct move from "TZif\0" to "TZif2" (with no intermediate "TZif1").
There should be no TZif1 files in the wild.

As RFC8536 indicates, the only difference between "TZif3" and "TZif2" is
that "TZif3" allows non-POSIX extensions to the TZ string at the end of the
file ("TZif2" only uses POSIX-blessed TZ strings).

    @dashdashado

On Fri, Mar 20, 2020 at 10:08 AM Tim Parenti <tim at timtimeonline.com> wrote:

> I believe Arthur meant to say "TZif2" and "TZif3", respectively.
>
> --
> Tim Parenti
>
>
> On Fri, 20 Mar 2020 at 10:05, Paul Ganssle <paul at ganssle.io> wrote:
>
>> Ah, thank you! I definitely should have realized at least the part about
>> using the NUL byte - and I see that in RFC 8536 now.
>>
>> However, I note that the RFC 8536 Section 3.1 makes no mention of a '1'
>> version with the 32-bit data:
>> https://tools.ietf.org/html/rfc8536#section-3.1
>>
>> Are the "TZif1" files non-standard, or are they prevalent enough that I
>> should be aiming to support them?
>>
>> Thanks,
>> Paul
>> On 3/20/20 9:43 AM, Arthur David Olson wrote:
>>
>> Classic files with only 32-bit data start out with "TZif\0" while files
>> with 64-bit data but no TZ string at the end start with "TZif1" and the
>> latest, greatest files start out with "TZif2"--so if you truncate and
>> change the "version number" byte to '\0' rather than '1' all should be well
>> (or at least it is on the system I use).
>>
>>     @dashdashado
>>
>> On Fri, Mar 20, 2020 at 8:49 AM Paul Ganssle <paul at ganssle.io> wrote:
>>
>>> Howdy,
>>>
>>> As part of the implementation of the new zoneinfo module for the Python
>>> standard library, I have been attempting to generate some version 1 files
>>> for test purposes (in the sadly likely event that some people only have
>>> version 1 TZif files deployed). I have done this by taking existing TZif
>>> files, truncating them at the second TZif header, and changing the version
>>> number in the truncated file.
>>>
>>> I notice, however, that with the 2019c version of zdump, the files
>>> generated this way are considered invalid:
>>>
>>> $ zdump --version
>>> zdump (tzcode) 2019c
>>> $ zdump -i -c2038,2039 $(realpath .)/America/Los_Angeles
>>> /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument
>>> $ zdump -i -c2010,2011 $(realpath .)/America/Los_Angeles
>>> /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument
>>>
>>> Interestingly, if I *do not* truncate the file and just change the
>>> version to "1" (in both the first *and* second header), it will read the
>>> file *and* it will clearly use the version 2/3 data:
>>>
>>> $ file Australia/Sydney
>>> Australia/Sydney: timezone data, version 1, no gmt time flags, 5 std
>>> time flags, no leap seconds, 142 transition times, 5 abbreviation chars
>>> $ zdump -i -c2200,2201 $(realpath .)/Australia/Sydney
>>>
>>> TZ="/tmp/zoneinfot3h5_eyf/v1/Australia/Sydney"
>>> -       -       +11     AEDT    1
>>> 2200-04-06      02      +10     AEST
>>> 2200-10-05      03      +11     AEDT    1
>>>
>>> So I guess my question is: does zdump support well-formed version 1
>>> files, and I am failing to create well-formed version 1 files, or does
>>> 2019c's zdump have no support for version 1 files?
>>>
>>> I'll note that this whole thing came up because I was wondering what
>>> zdump does for times after the last transition in a version 1 file. RFC
>>> 8536 indicates that this behavior is undefined - I was planning to hold the
>>> value of the offset after the last transition, but I figured I might as
>>> well check what zdump does.
>>>
>>> Thanks,
>>> Paul
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20200320/0bb808bb/attachment.html>