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. Thanks, Sergiusz (Oracle Database Development) On Thu, Jan 24, 2019 at 11:54 PM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> 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.
-- 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.