[tz] Version in zoneinfo files?

[Lester Caine]

On 28/10/15 23:37, John Hawkinson wrote:
>> 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.

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?

With the number of short notice changes TZ is currently having to cope
with, many diaries may need changes if viewed from outside the affected
locations and travel arrangements may need adjusting to match up with
the change.

But my other problem is with the local tz identifiers which have
different values in backzone pre-1970. In particular the UK zones which
I have historic data that was UTC normalized for the second world war
period, but gets miss displayed if backzone offsets are omitted. Some
European id's have a similar problem. The original data from some 20
years ago was normalized using older versions of TZ, but the chronology
did not work and when investigated, the missing elements of TZ data were
identified, but have now been flushed to backzone ... how can it be
ensured that the correct local times are displayed rather than the
incorrect ones provided by a non-backzone TZ?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk