<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
<br>
However, I note that the RFC 8536 Section 3.1 makes no mention of
a '1' version with the 32-bit data:
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc8536#section-3.1">https://tools.ietf.org/html/rfc8536#section-3.1</a><br>
<br>
Are the "TZif1" files non-standard, or are they prevalent enough
that I should be aiming to support them?<br>
<br>
Thanks,<br>
Paul<br>
</p>
<div class="moz-cite-prefix">On 3/20/20 9:43 AM, Arthur David Olson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJvZEYnfC8rAx0QF8ux7zV5LE5hJYmVCMnV5Bh21x0uPO7aNXw@mail.gmail.com">
<div dir="ltr">
<div>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).</div>
<div><br>
</div>
<div> @dashdashado<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar 20, 2020 at 8:49
AM Paul Ganssle <<a href="mailto:paul@ganssle.io"
moz-do-not-send="true">paul@ganssle.io</a>> wrote:<br>
</div>
<blockquote class="gmail_quote">
<div> Howdy,<br>
<br>
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.<br>
<br>
I notice, however, that with the 2019c version of zdump, the
files generated this way are considered invalid:<br>
<br>
<tt>$ zdump --version</tt><tt><br>
</tt><tt>zdump (tzcode) 2019c</tt><tt><br>
</tt><tt>$ zdump -i -c2038,2039 $(realpath
.)/America/Los_Angeles</tt><tt><br>
</tt><tt>/tmp/zoneinfon3c1bcna/v1/America/Los_Angeles:
Invalid argument</tt><tt><br>
</tt><tt>$ zdump -i -c2010,2011 $(realpath
.)/America/Los_Angeles</tt><tt><br>
/tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid
argument</tt>
<p>Interestingly, if I <i>do not</i> truncate the file and
just change the version to "1" (in both the first *and*
second header), it will read the file <i>and</i> it will
clearly use the version 2/3 data:<br>
<br>
<tt>$ file Australia/Sydney</tt><tt><br>
</tt><tt>Australia/Sydney: timezone data, version 1, no
gmt time flags, 5 std time flags, no leap seconds, 142
transition times, 5 abbreviation chars</tt><br>
<tt>$ zdump -i -c2200,2201 $(realpath .)/Australia/Sydney</tt><tt><br>
</tt><tt><br>
TZ="/tmp/zoneinfot3h5_eyf/v1/Australia/Sydney"</tt><tt><br>
</tt><tt>- - +11 AEDT 1</tt><tt><br>
</tt><tt>2200-04-06 02 +10 AEST</tt><tt><br>
</tt><tt>2200-10-05 03 +11 AEDT 1</tt><br>
</p>
<p>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?<br>
<br>
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.<br>
<br>
Thanks,<br>
Paul<br>
</p>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>