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