Forgot to hit reply list ...
On 11/05/18 12:30, Adriano dos Santos Fernandes wrote:
On 11/05/2018 06:54, Lester Caine wrote:
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?
Maybe you completely misunderstood it?
The thing about ambiguous times is only when converting from string to
timestamp.
Once it's converted, everything works.
I think I am reading it correctly. Oracle has a 'with local timezone' to
manage using the servers local time and this is STORED as a simple
TIMESTAMP ... no offset. So when the clock rolls back an hour you get
the SAME numbers again for an hour. I THINK the flag simply says how the
ambiguous time is displayed ... before dst or after dst ... so an hours
worth of logs is miss-placed either way.
See my example to Vlad.
So a given timestamp + 1 hour may return the same timestamp/tz, but with
different displacements.
Only if the raw data is not the same number ...
I suppose we do not want to add to our timestamps the suffixes 'before
dst ends' and 'after dst ends'.
The whole point of only storing UTC based data is that the raw number
stored is always sequential. Currently when the clock rolls back even
Firebird overlaps the times, but maintaining the server as UTC time
things are consistent and accurate. Trying to ALLOW the server to work
of local time will always be a mistake in my book, which is why the
current Firebird TIMESTAMP works fine and TIMEZONE is a second field on
the data. It's trying to merge the two without specifying the
limitations which is the problem. That and being able to specify just
which set of rules were used originally if your source of that data does
not provide a version flag! Even the secondary field approach is
hamstrung where the OS simply assumes there has only ever been one
version of TZ and you can't even check if that IS the current TZ version
... ICU does at least allow you to change the files, but I can't see how
to verify which version is being used? In addition, one has no way of
accessing a previous version so one can 'un-normalize' data and
re-normalize it with the current one. A TZdist source would at least
allow one to identify where a rule set has changed, but TZ distributions
contain the whole rule set each time so no quick way to validate
existing 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
