On 05/06/18 11:34, Mark Rotteveel wrote:
Is there any reason why post-1970 time zones need second resolution for
zone offsets? Or is there any other strong argument why second precision
is needed?
To be honest, I don't see why we should cater to an extremely uncommon
minor use-case which will likely be of no interests to the majority of
Firebird users, and that will be fraught with so many complications that
you'll probably need your own solution anyway if you need full precision
offsets pre-1970s. The TZ database does not guarantee correctness nor
completeness of its information before 1970, so using second precision
there will probably only lead to a false sense of precision.
The current argument with the way the TZ database is managed is a
separate problem. On one hand, one should perhaps make ANY application
give an error when trying to return ANY offsets for dates prior to 1970.
There IS no guarantee that the rule set being returned is correct as
much because the 'default' set of timezones no longer contain documented
transitions for pre-1970 dates if that gets in the way of simplifying
the post 1970 data. Yet SOME timezones have accurate transition data
back to the 1800's. There is nothing to indicate just which ones are
right prior to 1970 and which are truncated. But increasingly the data
is being enhanced with new material that has filled in many of the gaps.
And for a period in the late 1800's to early 1900's many of the well
documented transitions require seconds accuracy. The first problem IS
establishing just what view of is being provided by the tools being
used, and the fact some Linux distributions don't bother even updating
the current transition information does not help at all. But moving
forward, the tzdist requires that a rule set includes just what range of
dates it is valid from and to. The hole in that is just what does one
use prior to that initial date, and it SHOULD be the LMT for the
location you are look at. THAT is outside the scope of the TZ database
and comes under the banner of the geolocation lookup which would return
a valid timezone identifier and a location coordinate that gives the LMT
value. YES you can ignore all of that and simply stop the calendar at
1970 ... that would be the reliable way forward ... but with the volume
of material being archived even just relating to the 1900's, some means
of coping with the documented offsets should be available.
This IS a whole database of material in itself as even the timezone
identifiers are yet another controversial area, but if the basic
elements are correct then Firebird COULD host a more accurate setup than
any of the other engines ... and adding the geolocation element even
helps get the calendar right. The fact that we use 'day.time' natively
already makes Firebird ideal for sorting a lot more than just timezone!
--
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
