[tz] DST ends 2040 in Oracle database
Brian Inglis
Brian.Inglis at SystematicSw.ab.ca
Fri Jan 25 05:39:30 UTC 2019
On 2019-01-24 21:16, Sergiusz Wolicki wrote:
> On Thu, Jan 24, 2019 at 11:54 PM Brian Inglis wrote:
>> On 2019-01-24 11:30, Paul Eggert wrote:
>>> On 1/24/19 2:05 AM, Joachim Damm wrote:
>>>> we found one issue in the Oracle database that DST calculation is wrong
>>>> from 2040 and beyond.>>> Which DST calculation, exactly, and what are the incorrect and correct
>>> values? Perhaps you're thinking about Brazil, Iran, or Morocco. In these
>>> countries DST rules are so complex that they cannot be expressed in
>>> closed form in the tzdb notation, so tzdb lists rules explicitly for each
>>> year. Eventually this list has to stop, though, as the database and its
>>> maintainers' patience are finite. For Brazil and Morocco the list of
>>> exact predictions stops after 2037; for Iran, 2087.>>> Brazil and Morocco keep changing their DST rules, so any prediction past
>>> this year (much less past 2037) is dubious anyway. In contrast, Iran's
>>> rules have been stable since 2008, so I extended its exact prediction to
>>> 2087; there is some technical confusion about how to interpret Iran's
>>> rules after that, and even Iran is likely to change its rules before
>>> 2087.>>> If there's a real need to predict past 2037, what is the need and how far
>>> does it really go?>> Looks like tzdb supported 64 bit time_t from [19]95f, with updates in 2004h
>> and 2006b, when support for 64 bit tzdata was added.>> Oracle is old so may only support 32 bit tzdata up to 2038 for
>> compatibility: as with Java tzdb issues, they are due to Oracle design
>> choices.> This seems to be a design decision, indeed. Our internal compiler generates
> explicit transition rules up to year 2040 for all time zones with open-ended
> rules. The code comment references original zic compiler and its old 2038
> limit.> I am checking internally if there is more to the current design.
Please bear in mind that tzdb 64 bit data generated by zic now ranges from
-BIGBANG to +BIGBANG, or +400 years in the future if the rules are not
perpetual, when considering possible extension approaches.
[I have only looked at Oracle time zones for my own interest, not across the
whole date time range, or actually used them in production; the few thousand
instances at various gigs standardized on local server date time stamps in all
apps, often in US locales, so date time display was a GUI or reporting function.]
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
More information about the tz
mailing list