[tz] Version in zoneinfo files?

[Paul_Koning at dell.com]

> On Oct 28, 2015, at 7:03 PM, Lester Caine <lester at lsces.co.uk> wrote:
> 
> ...
>> This doesn't feel like a zoneinfo issue; it's a user interface design question for calendar applications.
> YES the user interface has to deal with the problem, but if it can't
> establish there is a problem because it can't identify that the stored
> version is different to the current version of offset then how can the
> user interface even warn you there is a problem. It needs to ask if the
> versions match ... and it may be that it is dealing with a diary fom a
> third source so a centrally sourced reliable version of TZ is critical.

Thanks, that helps.

I thought the discussion in this thread was about zoneinfo release identifier tracking.  That's pretty easy to do in principle.  

What you describe seems to require something different: information as to whether a particular timestamp may have changed meaning.  To do that, you need two things: (a) the zone identifier of the timestamp, and (b) the revision history of THAT zone.

I suppose that's doable.  It would be possible, for every distinct zone in the tzdata repository, to maintain a sequence number that is incremented when (and only when) some rule for that particular zone changes.  For example, in tzdata2015g, the sequence number for Turkey would be incremented, but the one for New York would not be.

Then for any stored timestamp, you'd keep the zone id plus the update sequence number.  If later on you get a new tzdata release, you could walk through the calendar and see if any entries have a changed sequence number for their zone.  If yes, that entry MAY have changed meaning.  It may not, depending on whether the particular time is affected by the change.  It may have been safely in summer time in both versions, or the change may have been one for historic timestamps only.  But that would be a good way to filter the data.

The question is whether maintaining that sequence information is something that could be added.  It would be an additional burden on the maintainer; hopefully an acceptably small one.

	paul