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