[tz] Getting current tzdb version in use
lester at lsces.co.uk
Thu Jul 26 10:25:45 UTC 2018
On 25/07/18 23:07, Paul Eggert wrote:
> Lester Caine wrote:
>> The simple question that the provision of a version number allows one
>> to answer is "what version of tz data was used to create the material
>> being published".
> Unfortunately that's not how things work. In practice the version number
> often does not provide that information; it merely provides a string
> that is useless or (worse) wrong. An example of this is the version
> string in the latest version of Fedora, which is merely "unknown". In
> practice there is no guarantee that a version string will be mappable to
> the data that it represents. There's not even a guarantee that differing
> data will have differing version strings.
>> there has to be some way to identify just what WAS used
> In practice the version string does not suffice for that. You can use
> 'zdump -i', though.
>> ETags ONLY work for the person who originally normalised the data!
> Sure, just as version strings are distributor-specific. ETags are no
> worse than version strings in this respect.
But isn't this the whole crux of the problem? We NEED some way to
identify if the data we are currently working with is current. Even a
'recent' RFC like tzdist manages to miss the whole point that the way
things NEED to work with this sort of changing data is having SOME WAY
to identify that one is working with the same progression of data
changes that the data publisher has been using? Currently there is no
way to ensure that everybody IS seeing the same information :(
I am thinking that the only safe way to manage ANY current cross
timezone diary of events is to also include the raw TZ data that was
used to create it! This is the only way one can ensure that the SAME
normalizations are displayed. tzdist SHOULD provide the same sequence of
data changes to everybody who is accessing the same publishing source,
but as yet we do not have any published sources of tzdist?
The fact that the system IS currently broken is no excuse and
"Unfortunately that's not how things work" has no place in the
discussion. We need to be providing a fix of some sort even if it is
only "data unavailable for that period"
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
More information about the tz