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.