On 29/04/2020 12:37, Paul Reeves wrote:
- The changes will, in all probability, more than 99% of the time, have no
relevance for over 99% of our users. But can one take the risk of
ignoring them?
Unfortunately this 'excuse' is quite prevalent in most actions relating
to TZ ... How do I ensure that data I distribute which includes World
War Two time offsets will be handled correctly if the user does not have
'backzone' on their setup. It's too difficult so handle pre-1970 data so
we will ignore it! The vast majority of users will never know ...
- Even if we can provide timely, automated updates how will a server
installation know to look for them? A task scheduler of some sort would
need to check. We don't have one built in to Firebird so it would mean
adding something platform specific.
This part of my objection to even having wasted the time to include a
restricted support for timezones AT ALL in FB4. The starting point of
solving the problem of handling potentially critical changes to TZ data
is tzdist, but while the RFC has been approved, no one has stepped up to
the plate to provide a feed. The whole point of tzdist is that you can
ask if a rule set has changed since it was last used ( or even since the
data was normalized ) and one can at least establish if the event you
published for say next week will be at the same UTC time if astronomical
observations have change the start of Ramadan for example. tzdist also
provides validation of the time frame over which a rule set is valid so
one can flag when there is no offset available for a pre1970 date.
This is not a firebird problem ... this is a problem with the core data,
and TZ is only required to provide post 1970 data. There is no source of
pre 1970 data that can be relied on despite the fact that a growing
historic record is being validated even in the TZ backzone data. SO
TODAY ... the best way of working is using UTC normalized data along
with additional fields recording location and version and type of tz
data used to provide that normalization! The FB4 'timezone' is yet
another unreliable data source! And this is the same for historic data
and published calendars for the coming 6 months ...
--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
