There are two issues that need to be distinguished:

1) leap years and leap seconds correct for precession/preserve
seasonal alignments;

2) elapsed-time measurements [typically] deal in the difference D =
t(j) - t(i), j >= i.

For 2) consideration of leap seconds is not just otiose, it is wrong.
For 1) it is necessary.

Consider the case of a pair of microsecond-scale time measurements on
either side of some midnight upon which a leap second is added to
Gregorian time.  Would you really wish to have a value of the form v =
1000000+a µsec figure in a sequence  for which mean(v) was 10 µsec?

More generally, think before you post.

--jg



On 1/12/12, Fred van der Windt <[email protected]> wrote:
>>>No use of the TIME macro need or should figure in this operation.  Any
>>>leap-second corrections would, for example, be washed out by the
>>>subtraction:
>>>
>>>(T + L) - (t + L) = T + L - t - L = T - t.
>>
>>Only if the interval t-->T does not span the introduction of the Leap
>> Second. If t is in Year X and T is in Year X+1 then if the last minute
>>of year X is 61 seconds long, your interval T-t will be off by one second.
>
> Not really: not in seconds anyway. If the interval contains 10 'normal'
> seconds and the leapsecond the application will calculate a length of 11
> seconds which is correct. Things might get a little bit weird if we try to
> convert the seconds back to minutes, hours and days that passed and
> attribute those to the actual (calender) date and time. Suppose your
> application starts running at 00:00:00 on a day with a leap seconds and ends
> after exactly 86401 seconds. One might think that it ran for 24 hours, 0
> minutes and 1 second and thus 'spanned' two days. But in fact it ran for 23
> hours, 59 minutes and 60 seconds and ran *exactly* from start till end of
> one calender day.
>
> It might not be a big thing for most applications but I'm sure there are
> circumstances where this makes a difference. The cpu-cpin during the
> leap-second probably prevents a lot of issues: it should prevent the
> scenario I just mentioned because an application cannot run till the end of
> the leap second: it would either end before the leap second or after the
> leap second on the next day at which point it's run did span two calender
> days.
>
> Fred!
> -----------------------------------------------------------------
> ATTENTION:
> The information in this electronic mail message is private and
> confidential, and only intended for the addressee. Should you
> receive this message by mistake, you are hereby notified that
> any disclosure, reproduction, distribution or use of this
> message is strictly prohibited. Please inform the sender by
> reply transmission and delete the message without copying or
> opening it.
>
> Messages and attachments are scanned for all viruses known.
> If this message contains password-protected attachments, the
> files have NOT been scanned for viruses by the ING mail domain.
> Always scan attachments before opening them.
> -----------------------------------------------------------------
>


--
John Gilmore, Ashland, MA 01721 - USA

Reply via email to