
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
participants (1)
-
Lester Caine