[tz] Getting current tzdb version in use

[Lester Caine]

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