[tz] zdump with version 1 files

[Paul Ganssle]

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
> <mailto: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/df5983f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20200320/df5983f8/attachment.sig>