[tz] Version in zoneinfo files?

Guy Harris guy at alum.mit.edu
Thu Oct 29 00:27:09 UTC 2015

On Oct 28, 2015, at 8:30 AM, Paul_Koning at dell.com wrote:

> On Oct 27, 2015, at 12:20 PM, lester at lsces.co.uk wrote:
>> The major problem all the time is identifying just what rules were applied when processing historic data, which may actually only be a current meeting diary. One can not assume that the current rule set actually correctly translates the current data if one set predates a later change. 
> I'm not sure I understood correctly what you intended.  Are you talking about this case:  I make a calendar entry for 9 am local time next year.  The calendar system translates that to UTC and stores that time in its database.  A few months later, the TZ rules change, and that same UTC time is now 10 am local.
> The difficulty with cases like this is that it is not obvious what the desired outcome is.  It might be that I want this event to occur at 9 am local time, and I don't care what that is in UTC.  But it is also possible that I want it to occur at whatever UTC corresponds to 9 am local -- for example, because this is a teleconference with people in several countries.
> It might even be true that the desired answer varies depending on which calendar entry you're looking at.  A dentist appointment is probably strictly in local time; a call with a colleague in another continent is probably primarily in UTC.
> This doesn't feel like a zoneinfo issue; it's a user interface design question for calendar applications.

...and an API/mechanism issue for the OSes on which those applications run, i.e. there needs to be a way for an application to be told "oops, a tz rule changed" or "oops, this particular tzdb zone's rules changed" or something such as that so that it knows that a meeting that's supposed to occur at "9 AM local time" isn't going to happen at the time it thought it was going to happen (if for no other reason than to ensure that a "you have a meeting in {5 minutes, an hour, ...}" message pops up at the appropriate time.

(That mechanism could also be used on systems wherein "system time" ticks at one second per second, even during leap seconds, to be notified that a new leap second will be inserted in the future and therefore that events with either local *or* UTC times in the future will have to have their "time of event, represented as system time" values recalculated.)

But that doesn't need a version stamp; all that the notification mechanism requires is a way to know that something changed, which could be delivered if the files were replaced at all (that might deliver a "false positive" if the file didn't actually change, but that might be rare enough not to care about), or delivered if anybody expressed interest in changes in a *particular* tzdb zone and its rules changed, and that should be checked by actually *comparing the data*, not by relying on a human-generated version number.

More information about the tz mailing list