On 07/19/2018 08:50 AM, lester@lsces.co.uk wrote:
The bottom line is that currently we have no way of knowing just what data is being supplied. Even if the data matches the raw tz version, it may or may not include the pre-1970 <tel:1970> data archived to backzone.
Yes, and this is partly why I have resisted putting version information into the installed files. Version info is typically not available unless you've merely cloned the development Git repository and have made no change to the data or to the 'make' parameters that select or alter the data, a situation that is reasonably rare in practice. It would take quite a bit of effort to get reliable version information in real installations, and nobody knows exactly what would be entailed in that effort. Since many people have requested version info I had compromised by putting a version string into tzdata.zi as a sort of experiment. The experiment has clearly failed so far. That being said, we can improve things a bit by putting into tzdata.zi information about whether the file 'backward' was used, as well as whether the (dicey) file 'backzone' and the (obsolete) file 'pacificnew' were used. We can also record whether the rearguard (or vanguard) data format was selected. Proposed patch attached. Harold, if you're changing your C++ library to look for "unknown", this patch might append some stuff to that "unknown" string.
On 2018-07-19 13:42, Paul Eggert wrote:
On 07/19/2018 08:50 AM, lester@lsces.co.uk wrote:
The bottom line is that currently we have no way of knowing just what data is being supplied. Even if the data matches the raw tz version, it may or may not include the pre-1970 <tel:1970> data archived to backzone.
Yes, and this is partly why I have resisted putting version information into the installed files. Version info is typically not available unless you've merely cloned the development Git repository and have made no change to the data or to the 'make' parameters that select or alter the data, a situation that is reasonably rare in practice. It would take quite a bit of effort to get reliable version information in real installations, and nobody knows exactly what would be entailed in that effort. Since many people have requested version info I had compromised by putting a version string into tzdata.zi as a sort of experiment. The experiment has clearly failed so far.
That being said, we can improve things a bit by putting into tzdata.zi information about whether the file 'backward' was used, as well as whether the (dicey) file 'backzone' and the (obsolete) file 'pacificnew' were used. We can also record whether the rearguard (or vanguard) data format was selected. Proposed patch attached.
Also whether zone.tab or zone1970.tab was used, the leapseconds.nnn... file used as leapseconds.list, REDO value {posix|right}_{only|right|posix}, and any other zic input selections I missed. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis wrote:
Also whether zone.tab or zone1970.tab was used, the leapseconds.nnn... file used as leapseconds.list, REDO value {posix|right}_{only|right|posix}, and any other zic input selections I missed.
Thanks for checking that. Aside from REDO, those things are not intended to be tailored by tzdb's makefile. For example, if a distributor chooses to install zone1970.tab as "zone.tab" then they'll need to alter the version string to let users know they didn't simply do something like 'make BACKWARD= install' but are instead doing their own thing. Although REDO is intended to be tailored by distributors, I had omitted it from tzdata.zi because tzdata.zi does not contain any information about leap seconds. (This is by design: tzdata.zi is intended to be useful for both leap-second-aware and no-leap-second-only TZif files, and installing both tzdata.zi and 'leapseconds' suffices for that.) However, I suppose it might be useful for tzdata.zi to propagate REDO info to indicate which leap second regime is supported by the generated TZif files on the installed platform, so I propose the attached patch to do that. This patch also widens the net to record weirder selections of input files.
participants (2)
-
Brian Inglis -
Paul Eggert