[tz] zdump with version 1 files

[Tim Parenti]

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/9e06f54d/attachment.html>