Time Libraries Rough Draft

[Keean Schupke]

Nope, I want correct intervals too... Although I am of the opinion that 
calendar calculations and time durations are independant, and very few 
applications will need to convert between the two (a rocket guidance 
system needs to pause exactly 3000 seconds, but doesn't care if that 
ends on a bank-holiday... my hotel booking system does not need absolute 
intervals... etc) So I don't see the lack of a leap second table as a 
show stopper...

    Keean.

Seth Kurtzberg wrote:

> 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.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>  
>