[tz] DST ends 2040 in Oracle database

[Phake Nick]

Except it is already year 2019 and 2038 January 19 is now only less than 19
years into the future. If one get a 20-year mortgage now, the final payment
day/time will already be after 2038. It's probably about time for
developers and vendors to consider the problem more seriously.

2019-1-29 01:27, Sergiusz Wolicki <sergiusz at wolicki.com> wrote:

>
> 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/20190129/14b66d35/attachment.html>