[tz] DST ends 2040 in Oracle database
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
More information about the tz