<div dir="auto"><div>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.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">2019-1-29 01:27, Sergiusz Wolicki <<a href="mailto:sergiusz@wolicki.com">sergiusz@wolicki.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.) <br></div><div><br></div><div>Thanks,<br></div><div>Sergiusz</div><div><font size="1">(Oracle Database Development)</font><br></div><div><br></div><div>P.S. Please note that I am not an authorized speaker for Oracle. Opinions expressed here are my own.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="m_-6543628423350645686m_1491183968753449276gmail_attr">On Fri, Jan 25, 2019 at 8:47 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank" rel="noreferrer">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Although tzdb's traditional .zi (text) files for New York have no expiration <br>
date, its traditional TZif (binary) format was limited to signed 32-bit <br>
timestamps and so stopped working after 2038. As Brian Inglis noted here:<br>
<br>
<a href="https://mm.icann.org/pipermail/tz/2019-January/027431.html" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2019-January/027431.html</a><br>
<br>
the TZif year-2038 problem was fixed in 2006. However, as Sergiusz Wolicki noted <br>
here:<br>
<br>
<a href="https://mm.icann.org/pipermail/tz/2019-January/027432.html" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2019-January/027432.html</a><br>
<br>
the Oracle compiler stops at 2040, inspired by the earlier TZif limit. So if you <br>
need to predict timestamps past 2040 you'll need to fix the Oracle compiler, or <br>
use some other compiler to translate the .zi files.<br>
</blockquote></div></div>
</blockquote></div></div></div>