Vigorous agreement here, but I would like to emphasize a little point... Paul Eggert <eggert@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@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@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.