[tz] DST ends 2040 in Oracle database

[Tony Finch]

Vigorous agreement here, but I would like to emphasize a little point...


Paul Eggert <eggert at cs.ucla.edu> wrote:

> 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.


Robert Elz <kre at munnari.OZ.AU> wrote:

> If your mortgage were in New York (probably a huge one, and 20 years
> might not be enough...) then the end date time of that 20 year mortgage
> should be recorded as "5:00 p.m. on the January 29, 2039, in
> New York City".
>
> If your mortgage is in Hong Kong (might need to be even longer than for
> New York!) the end date time should be recorded as "17:00 on 29th of
> January, 2039, in Hong Kong".

> Under no circumstances (other than specific agreement by the parties)
> should it be recorded as "2039-01-29 21:00:00 UTC" or
> "2030-01-29 09:00:00 UTC" (if I did the conversions in my head
> correctly) - that would always be wrong


There's a common error (which is embedded in the iCalendar specification,
so it's s difficult error to avoid) of recording future times as time +
timezone name, instead of time + place. Of course, the mapping from place
-> timezone name is not stable...


Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Shannon, Southwest Rockall: Northwesterly 6 to gale 8, decreasing 5 later.
High, becoming very rough later. Wintry showers. Good, occasionally poor.