[tz] DST ends 2040 in Oracle database
Sergiusz Wolicki
sergiusz at wolicki.com
Fri Jan 25 04:16:13 UTC 2019
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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190125/06eb8903/attachment.htm>
More information about the tz
mailing list