On Jan 6, 2007, at 13:47, Poul-Henning Kamp wrote:

In message <[EMAIL PROTECTED]>,
Ashley Yakeley
On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:

        B. i) Issue leapseconds with at least twenty times longer

This plan might not be so good from a software engineering point of
view. Inevitably software authors would hard-code the known table,
and then the software would fail ten years later with the first
unexpected leap second.

Ten years later is a heck of a log more acceptable than 7 months

Not necessarily. After seven months, or even after two years, there's
a better chance that the product is still in active maintenance.
Better to find that particular bug early, if someone's been so
foolish as to hard-code a leap-second table. The bug here, by the
way, is not that one particular leap second table is wrong. It's the
assumption that any fixed table can ever be correct.

If you were to make that assumption in your code, then your product
would be defective if it's ever used ten years from now (under your
plan B). Programs in general tend to be used for awhile. Is any of
your software from 1996 or before still in use? I should hope so.

Under the present system, however, it's a lot more obvious that a
hard-coded leap second table is a bad idea.

Ashley Yakeley

Reply via email to