On 26/10/2018 16:18, Adriano dos Santos Fernandes wrote:
On 26/10/2018 12:01, Lester Caine wrote:
On 26/10/2018 14:53, Dmitry Yemanov wrote:
Yes, it gonna be merged from PR soon.
What is the status for time zone support? Is it going to be
included in
Firebird 4 or not?
But the very limited mechanism being included does not support the
full range of TZ data as it's limited to minute accuracy. Also it will
only support TZ idents. We still have to rely on external tools to
provide proper time zone management for historic data ... basically
any data pre-1970 requires an alternative to the default TZ based
timezone rules, and second accuracy for the base LMT data.
AFAIR, you didn't mentioned a single real in-use DBMS doing these things.
Is there any point?
MOST options for adding timezone to databases are broken in some way,
and the SQL standard does not provide a clean method of carrying out the
process anyway?
The crude way that browsers provide timezone information has always been
broken, and provides no information as to the timezone being used by the
client, so providing information on events in the past or future has no
idea if the client is in a DST zone or not. MOST 'timezone' mechanisms
simply follow this process and so historic data is simply broken!
Bodging in a another half baked solution in Firebird is a joke! At the
very least it should be able to handle data in a clean way, and it's
date/time base already provides a cleaner solution than some other
engines so why wouldn't any TZ extension?
TZ itself is broken which does not help matters, and a clean reliable
data source is long overdue. Firebird COULD provide a base for that so
that normalized data can be relied on into the future. Using a base that
has no record of the version of data used to create it is simply playing
roulette with both historic and more critically FUTURE event data! That
both DST transitions and even simple offsets are being changed regularly
for political reasons needs a mechanism that can flag that normalized
data at the very least may need to be reviewed, and having no idea just
what timezone data is being used is somewhat pointless? Being able to
validate stored offsets against current offsets is an essential part of
a reliable TZ management process.
--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
