Time Libraries Rough Draft

[Seth Kurtzberg]

Aaron Denney wrote:

>On 2005-02-10, Scott Turner <p.turner at computer.org> wrote:
>  
>
>>On 2005 February 10 Thursday 07:19, Simon Marlow wrote:
>>    
>>
>>>On 10 February 2005 12:12, Marcin 'Qrczak' Kowalczyk wrote:
>>>      
>>>
>>>>And the simple fact that obtaining TAI from systems in use requires
>>>>periodic updates of the leap second table causes other difficulties.
>>>>        
>>>>
>>>This is a vitally important bit of rationale which has emerged from the
>>>current discussion.  I certainly didn't fully appreciate the
>>>difficulties with basing the library on TAI before,
>>>      
>>>
>>Another significant bit for me was the realization that TAI is no good for 
>>scheduling future events on an everyday calendar. If I schedule a new year's 
>>celebration for Jan 1, 2006, that would be represented in TAI as 1514764832.0 
>>seconds after the epoch. If a leap second is inserted at the end of 2005, 
>>then my celebration at 1514764832.0 TAI will be premature. Even if we go to 
>>the trouble of keeping our leap second tables current, this is still a 
>>problem.
>>    
>>
>
>Yes, because TAI is a clock, not a calendar.
>
>  
>
We are getting bogged down in the terminology here.  My problem is that, 
as proposed, the library will give wrong answers.  Having a nanosecond 
granularity library that can't even manage one second accuracy doesn't 
seem useful to me.  Apparently, though, I'm in the minority here, so 
I'll let it go.

The comment about scheduling is not correct, because the leap year 
correction is always available.  To me, it is more important to get the 
correct answer when, say, finding the amount of time that has passed 
from one timestamp to another.  I can't see the logic in a library that 
returns incorrect answers, because to return correct answers is more 
difficult.

I guess those people who intend to use it don't care if the interval 
results are correct.  I do care, but I'll have to implement it myself 
since I appear to be a minority of one.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/libraries/attachments/20050210/22b32c28/attachment.htm