Should time zone info files be tagged with the tzdata version number?

Jonathan Leffler jonathan.leffler at
Sun Nov 25 03:16:31 UTC 2007

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.

Has anyone ever suggested embedding the version number of the time zone data
files (eg "2007i") into that space, so that you can tell immediately where
the data comes from when looking at the file?

If not, may I make the suggestion?

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?  I would suggest
mandating 6 bytes, null terminated, for the version string.  I don'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's problem anyway (I plan to be retired
long before that's an issue).

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.

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.  That could be fixed if a VERSION file was released
with the data, so each new release had it release number in the file.  The
zic program could look for that file - or take an optional argument that
specifies the version.  Since '-v' is for verbose, maybe '-z YYYYv'?

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).  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?  Perhaps it would use "-o N" for N in 0, 2, 3 (and maybe 4)?

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?  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 'Rule', 'Zone', 'Link' and 'Leap' lines.

Jonathan Leffler <jonathan.leffler at>  #include <disclaimer.h>
Guardian of DBD::Informix - v2007.0914 -
"Blessed are we who can laugh at ourselves, for we shall never cease to be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tz mailing list