Re: Introduction of long term scheduling

From: Ashley Yakeley <ashley_at_SEMANTIC.ORG>
Date: Sat, 6 Jan 2007 14:23:31 -0800

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

> In message <4D066C24-4B37-466B-8D8E-E51A7F59D1B1_at_semantic.org>,
> Ashley Yakeley
> writes:
>> On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:
>>
>>> B. i) Issue leapseconds with at least twenty times longer
>>> notice.
>>
>> 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
> later.

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
Received on Sat Jan 06 2007 - 14:24:23 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT