[tz] DST ends 2040 in Oracle database

Paul Eggert eggert at cs.ucla.edu
Tue Jan 29 00:00:30 UTC 2019


On 1/28/19 9:26 AM, Sergiusz Wolicki wrote:
> 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?

Yes, problems in this area are often software glitches that reflect 
fundamental misunderstanding of predicting future timestamps (or 
guessing past ones).

For example, the software might be told something like "This bond 
payment is due at 17:00 Morocco time on January 28, 2029", one program 
uses tzdb 2018i and another program uses tzdb 2018g to convert that 
timestamp to UTC internally, and their internal UTC timestamps disagree. 
Here the real bug is assuming that an operation like "convert from 
Morocco time to UTC" is a portable and repeatable operation, which it 
certainly is not for future timestamps, and sometimes not even for past 
timestamps.



More information about the tz mailing list