[tz] zdump with version 1 files

[Arthur David Olson]

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