On 15/12/17 15:41, Leyne, Sean wrote: > Lester > >> The problem I had in the past was with meetings being moved over a DST >> boundary. And this was in a SINGLE timezone. The software was normalizing >> everything to UTC time, so that it could be displayed in local time of the >> client, but what was forgotten in the software was which timezone was used >> to store the data. It was JUST stored as an offset, so when the meeting >> moved the change in DST was missed. > > Missed how? > > That seems to be an application implementation issue/bug related to how it > calculated the local time, not an issue of use of UTC offset. If tzdist was actually up and running, when a mobile device re-synced after being offline it would see a change of offset had happened *IF* the software was designed to work with that trigger. THAT part of the system is currently missing, so what you tend to get is that the event is shown an hour out of sync with what is NOW current local time. Participants in another timezone are expecting a live video link at say 11AM, but the local site is either early or late. A major medical conference was messed up a few years back when the Middle East session changed offset due to Ramadan's astronomical observations being at odds with the guess on TZDB. The system needs to be able to cope with ALL reasons for changes to tz offset ... and have some way of flagging it. Not a database problem per-say but the means of converting a timezone time from one location to another needs to be consistent given at times things are very unstable.
>> The fact that some timezones have >> DST changes and some do not means that one needs to store the the actual >> rule used and not just an offset. But more than that, one HAS to remember >> the version of the rule being used! > > Let's say we do that. > > Further, let's say that tomorrow the New York state announces that starting > next year there will be no DST. So, the definition of the "America/New York" > time region is affected, which as a timezone, is used by millions of people > in the Eastern US, so all their events would be affected. > > What would you expect a user/developer/the system do to handle this change? > For both pre-change and post-change events? Problem 1 ... A genealogical database has all the times stored UTC normalized. Currently TZDB is not defined as being accurate pre-1970, but a substantial amount of that information is accurate. So we can use it, but as corrections are made, it is important to know just which version of TZDB was used to create the data, and *IF* a change of offsets are triggered by a change in version then either those records are updated and tagged with the new version or they are maintained with the old TZDB version ... Current historic data that has been normalised in the past tends to be suspect because one has no idea just which version of TZDB was used to create it, and Paul has culled a lot of historic data to backzone which some OS's don't even bother to load! Problem 2 ... Some political administration decides to change offset to align with another region, or drop DST as is being discussed in several areas. We have a diary of international events using the old data and JUST like the historic material, we need to be able to detect that the events that were published prior to the change of offset have moved. We may not be able to automatically update the event if it NOW has to happen an hour earlier or later because of other related events such as a satellite link scheduled IN UTC time, but we can at least flag that the event needs to be checked. If a plane has taken off and now lands an hour later because of some local coup one knows what time a meeting was due at but need a new calendar of events to manage the changes. Problem 3 ... You have an event scheduled for 10AM Local summer time but only have the offset from UTC. It's pushed back a week ... into winter time ... but you don't know that this offset involves a DST change so the new time is an hour out! THAT is the one I had on a number of PHP software packages when PHP introduced TZ and ran it from the browser offset! The DATABASE needs to know what the rules are and it is simple to define them as offsets, but personally I don't think that solves anything. It just makes things worse. An offset timestamp is NOT usable timezone data only current offset times. -- 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
