On 11/05/18 14:27, Adriano dos Santos Fernandes wrote:
On 11/05/2018 10:10, Lester Caine wrote:
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
No. It stores the time without a time zone, but considers the time zone
as being the "database time zone".
Database time zone is not server local time zone.
In the end, it's better than our TIMESTAMP WITHOUT TIME ZONE, that one
is just it, and when reading it it's considered to be in the session
time zone.
There is a specific note about the 'problem' in the Oracle notes.
Lost the link to the page I was reading ;)
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 ...
Do not understand you.
If the machine clock goes back one hour because of a DST transition, the
current time overlaps and the same set of numbers are used twice.
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,
There is no problem with the current server time. It's always mappable
to UTC and hence mappable for any time zone.
Except for the overlapping hour or other overlapping changes.
but maintaining the server as UTC time things are consistent and accurate.
This is necessary only when you deal with times and time zones
incorrectly. It's just easier to think the earth as a flat time zone.
It is much easier where a system has clients world wide the one
standardises on a static base, and UTC is the best base for that.
Displaying that information in a local timezone is also easier to manage.
--
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
