[tz] DST ends 2040 in Oracle database
dot at dotat.at
Tue Jan 29 13:43:12 UTC 2019
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...
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.
More information about the tz