<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">paul@ganssle.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

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