[tz] Version in zoneinfo files?

[John Haxby]

On 29/10/15 00:17, Lester Caine wrote:
>> 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.
> SIMPLE things like that are not the problem. Where the problem arises is
> when the 9:00AM UTC Meeting in one location is advertised in several
> time zones and one of those time zones has a change of offset. The
> medical conference I quoted was across four time zones in Europe and the
> middle east, but one of the satellite links started an hour before the
> delegates arrived because of the change in DST at short notice. Don't
> ask why nobody even thought about the problem ... the local programs had
> been printed only with local times and the local organisers simply did
> not think ... current calendars do not do multi timezone well?

All three of the ones I use handle timezones well.   Meetings are
typically scheduled by the organizer in the organizer's timezone and
show up at the right (local) time in everyone's calendar (even in Turkey).

It's not perfect, of course.  In one case, the organiser was having a
bad day, tried to set his machine to use GMT to organise the meeting,
got it wrong and assumed and assumed that the calendar application was
broken and turned up an hour late (or early) to his own meeting.   In
another case, the maintainers of the calendar system hadn't updated the
server's tzdata since 2009 which made it remarkably difficult to
schedule a regular meeting for a consistent time of day from Moscow.

I suspect in the case of the satellite problem that either someone was
trying too hard to be helpful rather than a broken calendar.  (Unless
they were using the same calendar application that hasn't updated its
tzdata since 2009.)

jch