Concerning Time.TimeDiff

[Graham Klyne]

At 18:56 16/06/03 +0200, Dylan Thurston wrote:
>On Mon, Jun 16, 2003 at 04:42:53PM +0100, Graham Klyne wrote:
> > ... I think it's quite usual for people and applications to deal
> > with a day as a consistent time interval without concern for
> > possible leap seconds, so dealing with days as intervals of 24*60*60
> > seconds is useful for a majority of applications that deal with such
> > intervals.
>
>What about the fact that days are not actually intervals of 24*60*60
>seconds (as I'm sure you know)?  Most applications don't care, but
>it's crucial to give correct and unsurprising results.

This area is something of a judgement call.  I agree with your comment 
(below) about the complexity of leap second support.  (Worse, impossibility 
for far future dates, because I understand the occurrence of leap seconds 
is not even known very far in advance.)

The view I was expressing was based on an opinion that for the majority of 
"ordinary" applications, treating a day as anything other than 24*60*60 
would be surprising.  If I want to say that an event takes place exactly N 
days after some previous event, say 2003-06-17T10:39:00+01:00, in the 
overwhelming majority of cases (and this is a judgement rather than an 
assertion) I expect it would be surprising if the clock time of the later 
event were not exactly T10:39:00+01:00, or equivalent.  (Using RFC3339 [1] 
notation :-)

Therefore, in an implementation of time intervals that includes a measure 
of days would be very clear that for that purpose, a day is defined as 
24*60*60 seconds.  Of course, another perfectly good approach would be to 
stick to seconds and picoseconds, and let the application figure out larger 
interval units.

My judgement is based on my own past experience or writing and using such 
code, which is more than none at all, but not especially extensive.  If 
there's any significant concern about ignoring leap seconds in time 
intervals, then rather than debate it at length, I'd rather just stick to 
seconds.

>I'm worried that the complexity to deal with leap seconds will end up
>being just as complicated as the complexity to deal with more general
>TimeDiff's as in the current library, in which case it may be
>necessary to bite the bullet and specify the behaviour of TimeDiffs
>completely and accurately.

Yes, I do agree that behaviour of TimeDiffs should be should be specified 
"completely and accurately", including any simplifying assumptions such as 
possibly ignoring leap seconds.

#g
--

[1] http://www.ietf.org/rfc/rfc3339.txt


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E