On 12/05/18 07:43, Mark Rotteveel wrote:
Like Macau, a lot of historic data has been added and for databases
handling historic material it would be nice if there was a way to have
matching correct offsets? Or we ignore the builtd in tools and
cintinue to rely on external functions ...
To be honest, I think the majority of our users will have no need for
correct pre-1970 time zone data. I suspect none of the major database
provide it either.
Lets not get hung up on these esoteric parts of time zones.
In part I can accept that, but short cuts need to be documented? It is
not common knowledge that TZ data IS questionable prior to 1970, and
with the amount of research being done on even just the second world
war, knowing that time one is normalizing needs knowledge of the
situation at that time. My digging into the German occupation of the
Channel Islands threw up the errors there with local time being adrift
from the rest of the UK!
Dropping seconds accuracy and merging timezone into the same restricted
data field is a shortcut that has major limitations. First, prior to
standardised time we assume mid-day happened when the sun was directly
over head, so the rule for the whole world was LMT. Using Greenwich as a
timing point may only date back to 1675 and was only officially adopted
in 1880 but it is the current base. America joining in 3 years later and
the basis for timezones was established in 1884. So any date prior to
1884 do not have timezones and are identified by their LMT offset. While
time prior to the introduction of accurate measuring devices may be
somewhat academic and millisecond accuracy totally pointless, that early
19th century time had well documented differences of seconds. So any NEW
facility should at least permit those variations to be handled. Or
simply say 'the Firebird TIMEZONE extension is only accurate for dates
post 1970'.
In my book a normalized time consists of FOUR elements. UTC based time,
offset, rule set, version. I don't think any of the current 'solutions'
offered by any database respects this and so even for CURRENT diary
events they have no way of flagging when the calculated offset has been
compromised. TZdist was an attempt to plug these holes, but has yet to
even start being used despite the fact that it is the perfect solution
for time management on 'internet devices'. I have also been advised of a
new ietf task group to address the Geolocate Extension and the Time Zone
Information Format bu these will be some time reaching an RFC stage :(
--
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
