[tz] Version in zoneinfo files?
pganssle at gmail.com
Thu Oct 29 00:12:13 UTC 2015
Agreed - what Lester seems to be describing sounds more complicated than
What might be useful is if you, for whatever reason, want to notify someone
that a meeting time specified in UTC has changed in the local time zone of
one or more of the participants.
That said, what is the point of maintaining per zone versioning? That seems
needlessly complex when retrieving and processing two tzdata tarballs is
incredibly quick (especially if you only care about a limited number of
zones). Then you can just process the date of interest using the old
version and the new version and see if they resolve to the same time in UTC
On Oct 28, 2015 8:02 PM, "John Hawkinson" <jhawk at mit.edu> wrote:
> Lester Caine <lester at lsces.co.uk> wrote on Wed, 28 Oct 2015
> at 23:03:56 +0000 in <5631545C.8080704 at lsces.co.uk>:
> > > 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.
> I still can't parse this (try again with smaller, shorter, sentences
> please?), but I think you may misunderstand the problem.
> The time and the zone must be stored, becuse whther the time shifts
> with DST is a function of the zone. As long as the calendar app
> stores some things like "9:00am US/Eastern" (for a dentist appointment)
> and "13:00 UTC" (for an international conference call), calendar
> apps should work well.
> --jhawk at mit.edu
> John Hawkinson
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz