[tz] DST ends 2040 in Oracle database

[Brian Inglis]

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.