[tz] Identifying timezones ...

[Lester Caine]

I feel it's worth pointing out something which seems to have got lost
during the current discussion ... The shorthand abbreviation for a
offset may or may not indicate that a time is affected by daylight
savings. Taking the simple example of 'BST' which is an abbreviation
that has a sort of statutory definition in the 'British Summer Time'
laws, one knows that there is a related start and stop date and so
adding a couple of weeks delay may also require a change of offset, but
if the same date is posted as 'GMT' there is no information that 'BST'
changes are relevant. I get the impression that with all of the current
upheaval in Russia that some areas are introducing daylight saving,
while others are standardising on one or other of an 'abbreviation'
without the matching switch?

The ONLY ident that correctly provides the correct time sequence. both
current and historic is the full name, but even that now gets tricky
with the improving accuracy of pre 1970 data? This new data either needs
it's own 'shorthand', or we do need to drop the shorthand!

If one is doing the job of providing a date and time which must sit
accurately in an historic context, then the 'local' offset from UTC has
to be stored as the timezone name and VERSION of tz used. Simply using
'EST' is of no use what so ever, while just using 'Asia/Tomsk' falls
flat on it's face when you don't know which rules were active then the
timestamp was stored.

In my book the only clean way of managing historic data is to maintain a
UTC normalised timestamp along with the location data to provide a local
time. If an event occurs that casts doubt on the offset then a new UTC
time may needed, and it's the identified change that flags up the advise
that needs to accompany the notification. On current calendars that may
well be that Ramadan is a week early or late, but the 'abbreviations'
used do not necessarily change as a result? They are just a piece of
text accompanying the rule which should actually be a translated note
from the rule set since abbreviations may not be unique.

-- 
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