[tz] Getting current tzdb version in use

[Michael Douglass]

We didn't add everything we wanted to in the RFC because it's a balance 
between getting it all or gettign nothing.

Our hope is that each timezone definition will have some sort of version 
- maybe the latest version for each of the rules.

That would allow update of a single tz.

I understand that redistributors may want to add their own data or 
modify the data but that just means they need to add their own version. 
And yes they do need to be an increasing sequence.

A simple sequence number might suffice for versioning.

And I agree - it's broken now is more of a reason to do something than a 
reason to do nothing


On 7/26/18 06:25, Lester Caine wrote:
> 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"
>