[tz] DST ends 2040 in Oracle database
Sergiusz Wolicki
sergiusz at wolicki.com
Mon Jan 28 17:26:24 UTC 2019
The Oracle compiler is an internal tool and the binary timezone files are
in an Oracle-internal format as well. Therefore, if the current Oracle
behavior is to change, this must be done by Oracle. However, there is a
possible performance trade-off in supporting more years or supporting
open-ended rules. An Oracle database processes potentially massive amount
of data and any slowdown in date processing may create a significant
regression in total query response times for most customers who do not need
dates over 20 years into the future. Therefore, this issue needs to be
evaluated carefully.
Moreover, I would like to point out that from practical point of view, this
does not look like a real problem for the use case given. When an expire
date is 27 years into the future who cares if it is one hour less or one
hour more? I would expect expire dates so far in the future to be without
time component anyway. To give an advice for a workaround I would need to
understand why the time component is needed and how you account for the
fact that DST rules in 20 years may be different from current ones anyway,
so whatever you see today may be different from what you see after a DB
upgrade in a few years. (See EU plans to abandon DST.)
Thanks,
Sergiusz
(Oracle Database Development)
P.S. Please note that I am not an authorized speaker for Oracle. Opinions
expressed here are my own.
On Fri, Jan 25, 2019 at 8:47 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
> Although tzdb's traditional .zi (text) files for New York have no
> expiration
> date, its traditional TZif (binary) format was limited to signed 32-bit
> timestamps and so stopped working after 2038. As Brian Inglis noted here:
>
> https://mm.icann.org/pipermail/tz/2019-January/027431.html
>
> the TZif year-2038 problem was fixed in 2006. However, as Sergiusz Wolicki
> noted
> here:
>
> https://mm.icann.org/pipermail/tz/2019-January/027432.html
>
> the Oracle compiler stops at 2040, inspired by the earlier TZif limit. So
> if you
> need to predict timestamps past 2040 you'll need to fix the Oracle
> compiler, or
> use some other compiler to translate the .zi files.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190128/62e025db/attachment.htm>
More information about the tz
mailing list