I note that the time zone information file has a version number byte and 15 bytes of currently unused (must be zero) space at the heading.<br><br>Has anyone ever suggested embedding the version number of the time zone data files (eg &quot;2007i&quot;) into that space, so that you can tell immediately where the data comes from when looking at the file?
<br><br>If not, may I make the suggestion?<br><br>Presumably, the version byte would need to become version 3 -- or would we need both version 3 and version 4, with version 3 being like version 0 with 32-bit timestamps only plus the data version and version 4 being like version 2 with both 32-bit and 64-bit time stamps?&nbsp; I would suggest mandating 6 bytes, null terminated, for the version string.&nbsp; I don&#39;t think the version numbers for the data files ever got beyond one cycle of the alphabet in a year, so that works for almost the next seven thousand years - and after that, it is someone else&#39;s problem anyway (I plan to be retired long before that&#39;s an issue).
<br><br>The obvious advantage of this is that an appropriately modified zdump can show which set of rules the time zone information file was created from, which in turn would help decide whether an update is called for.<br>
<br>The only immediate downside I can see is that the version information is not readily available in the distributed files - other than as part of the gzipped tar file name.&nbsp; That could be fixed if a VERSION file was released with the data, so each new release had it release number in the file.&nbsp; The zic program could look for that file - or take an optional argument that specifies the version.&nbsp; Since &#39;-v&#39; is for verbose, maybe &#39;-z YYYYv&#39;?
<br><br>I also note that Sun Solaris 10 appears to use the version 0 format for its time zone info files (zic --version gives 7.128).&nbsp; Would it be relevant to provide an output version selector option to the zic command line - so that files could be generated in version 0, 2 or 3 (or even 4) format when appropriate?&nbsp; Perhaps it would use &quot;-o N&quot; for N in 0, 2, 3 (and maybe 4)?
<br><br>Or do we need a more complex scheme where each of the separate data files gets a version tag whenever it is modified, so that you can tell that, for example, the northamerica rules have not changed recently, whereas the asia ones have changed?&nbsp; This would presumably need a new entry type in each data file - maybe Version followed by a version number, or Vrsn to be consistent with &#39;Rule&#39;, &#39;Zone&#39;, &#39;Link&#39; and &#39;Leap&#39; lines.
<br clear="all"><br>-- <br>Jonathan Leffler &lt;<a href="mailto:jonathan.leffler@gmail.com">jonathan.leffler@gmail.com</a>&gt; &nbsp;#include &lt;disclaimer.h&gt;<br>Guardian of DBD::Informix - v2007.0914 - <a href="http://dbi.perl.org">
http://dbi.perl.org</a><br>&quot;Blessed are we who can laugh at ourselves, for we shall never cease to be amused.&quot;