[tz] Fiji DST Oct 26

Clive D.W. Feather clive at davros.org
Tue Oct 21 05:54:19 UTC 2014

Deborah Goldsmith said:
> Given that, it is better to have a default which correctly predicts whether DST will happen at all. Getting the transition date right is a secondary (but still highly desirable!) consideration. If we have the default as no DST and there is DST, then customer?s time stamps might be wrong for weeks or months, until an update can be released. If the transition date is wrong but there is still DST, then their time stamps are wrong for a few days, maybe a week or two (the difference between the predicted and the actual transition date). The latter is far preferable for any tz client whose deployment cycle takes weeks or months.

Actually, I'm not sure that's true.

If we don't have any change in there and one happens, timestamps are wrong
for months but it should be obvious to people that they are wrong and need

If we put a wrong prediction in, people may see shifts in their data and
assume they are correct, not realizing that they started a week earlier
or later than they should have done.

I'm not going to make a big fuss about this (I don't have a dog in this
race), but it's an opposing thought for people to consider.

Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

More information about the tz mailing list