Should time zone info files be tagged with the tzdata version number?
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@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
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?
Not that I know of. But I'm not sure it's worth the hassle, as people make changes to the source files on their own, and if that happens the "version number" in the output will be unreliable.
On Nov 25, 2007 8:44 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
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?
Not that I know of. But I'm not sure it's worth the hassle, as people make changes to the source files on their own, and if that happens the "version number" in the output will be unreliable.
They do? Well, yes, they probably do. OK - fair enough. I may end up putting some version information in the file along the lines I suggested for the system I'm working towards. Or it may become moot if I end up storing the time zone information directly in the database - though since there are client applications as well as the server to worry about, I am thinking it will be better to keep the data out of the database. (That said, the transactional capability of the database has its advantages for changing versions of the time zone information.) Are there any thoughts anywhere about using those 15 zero bytes for any purpose that I'm likely to run foul of? I know I could run foul of a change at any time, but has any such use been mooted as a possibility at this point? -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
participants (2)
-
Jonathan Leffler -
Paul Eggert