I was having a proper look through the Oracle timezone documentation and
thinking 'how can you get it so wrong'. Does it REALLY have a
ERROR_ON_OVERLAP_TIME flag because it allows the server local clock to
be used raw. Actually this is no different to the current situation
without managing timezone at all since for those areas of the world that
do implement daylight saving there is an ambiguous hour every year and
most of the time it is simply ignored? Log files get overlapping data
and one lives with it?
Over 20 years ago I realised that the only way to run ANY system that
involves DST was to use UTC only for the server clock. Later adding
international material with additional timezones slot nicely into this
approach, and ALL you need is the timezone for the client to be able to
display material in that data in local time. Or the timezone for the
location if the client resides in another timezone.
The main problem is that most people only think in 'local time', so when
you set a meeting for 9AM just which 9AM is not a factor. Moving that
meeting a week is only a problem if there is a DST transition about to
happen, and with these not happening at the same time if the meeting is
between staff from various timezones the new meeting may be an hour
either way depending on what transitions have happened. Even discussions
on the TZ list have a camp where it is 'not our problem' what happens in
the real world, but when you are creating a timetable of events over a
period of time with links to different international locations then a
change to one transition - while highly unlikely - should at least flag
that there IS a conflict that needs correcting. In order to do that one
needs to know that the data used to create the calendar (version 2018e)
has now been replaced by something else.
In a database it is the historic material that needs to be SAFELY
managed. Coming up in the next TZ update will be a change to the Macau
rule set that completely rewrites the historic transitions. While it is
unlikely this will affect any current data sets world wide, there are
many people working through paper archives just like P Chan has done for
Macau to correct the historic rule sets so once a system is in place
that ALLOWS easy normalization of data it should protect the integrity
of that data.
--
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
