On 11/05/18 17:31, Adriano dos Santos Fernandes wrote:
Here is the first README version for the time zone feature.
https://github.com/FirebirdSQL/firebird/blob/work/time-zone-support/doc/sql.extensions/README.time_zone.md
So there is no provision to support the initial LMT offsets for those
rule sets that provide them? These are second accuracy and for example
the new rules for Asia/Macau moved that one from 7:34:20 in 1911 to
7:34:10 in 1904. That is the first time that region started using a
centralised time offset rather than Local Mean Time. Most timezones have
a second's accurate initial offset, and some have a number of them as
the 'novelty' of railway and similar times changed to more centralised
and then national times.
Reading between the lines, the rule sets used are those provided by ICU
rather than the the Oracle approach of providing it's own external files
built from TZ distribution versions? Only the full TZ/backzone table
with it's own numeric mapping is compiled in the source code? So it is
the ICU library that needs hacking to provide earlier views of the rule
sets? Has a way of identifying just which rule set is being returned
been identified so we can query it and store it with the data? (I'm
currently using PHP's library to handle timezone data - and only
returning UTC normalized values to the database)
Another restriction on timestamps could do with being addressed.
Historic genealogical dates can predate January 01 1 so it is quite
common to switch to a different date/time library based on unix epoch
anyway to make managing the data easier ... this is of cause always a
UTC value. It's been so long since I made that switch I'd forgotten that
many fields are bigint now rather than timestamp anyway.
If time permitted I would build my own TZdist server using Firebird as
the database and managing the history of TZ changes in a way that one
could identify where normalised data needs refreshing. All the data is
readily available and the API for TZdist while cumbersome is elegant
when supplying raw offset data to work with. It SHOULD be able to
identify when an event's UTC time has changed due to a short notice
change of offsets and does not need to be restricted to the limitations
of the TZ release process.
https://tools.ietf.org/html/rfc7808 if you have not seen it. It provides
nice tidy definitions of many of the key terms. It also fails to define
just how time zone names are created3 leaving that to the 'publisher'.
--
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
