On 24/04/2019 14:44, Adriano dos Santos Fernandes wrote:
Data should be validated/fixed when new rules are installed.
So IMO the problem is letting OS (or some shared component) be the
master of time zones rules instead of Firebird engine having its own
controlled table.
Exactly ...
And the fact that TZ has been dragging it's feet even to provide version
numbers for each update does not help things!
The key element that needs to be handled is the fact that there HAS been
a change while a device was asleep for whatever reason. But having to go
though a large volume of normalised data is not the way to fix it
either. One needs to be able to read a record and know if it's valid
against current rules ... and with the current drive to eliminate DST in
parts of the world, those records could well be a current set of diary
entries!
PRACTICALLY given that normalization is such a minefield, it still makes
sense to store a local time and location rather than trying to make
UTC/TZ work. We use UTC for real time activities such as log file time
stamps against a UTC based clock. Displaying these in local time is
often academic and would never store a TZ flag with them as it's the
client local time you want not the events local time. While you want to
be able to compare the time of events in different timezones, the FB4
timezone data type is the last thing one would use to do it! Much of the
data you will want to compare against will be from other sources, and
the lack of a reliable system of identifying what rules were used to
create that data is the problem tzdist was intended to at least help
with. So for example, when one gets off the flight and your tablet
checks it's diary you can see that perhaps the meeting you are attending
has now changed time due to a short notice change to local DST ... and
as has happened in recent years the meeting may already have started an
hour early!
What IS required is a database with identified rule sets and change
records relating to those so one can take a normalized time, identify
that the normalization is now suspect, so you need the original local
time using the recorded rule used, and then a new UTC time based on
probably the new rule set ... without access to the version of the rule
set used you do not know if the normalized time has changed or not ...
and the OS simply updating the rules without any warning causes all
sorts of problems?
--
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
