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@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