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