System.Time.Clock Design Issues

[Seth Kurtzberg]

When you say "defined for all history and the future", does that mean 
literally what it says?  It accounts for the adjustments to the Calendar 
through various centuries, some of which are gaps of over a month (that 
is, corrections to get the calendar back in the right place, by adding 
more than a month or skipping more than a month)?  I only have one user 
who bitches about this (he's an archeologist, so he has a reason, 
although his expectation may not be as reasonable as his reason).  I'm 
not saying this is a requirement, I'm simply asking whether TAI can 
really handle these situations.

Seth

P.S.:  If anyone receives this message as HTML or as combined plain 
text/html, please let me know.  I think I've got the problem solved as 
long as haskell.org is in the address, but it may not be solved for 
addresses in other domains (such as John's above).  Thanks, the response 
will help me troubleshoot.  My logs are indicating that something went 
out as plain text, but I still get complaints that they arrived as 
html+plain text.  TIA

John Meacham wrote:

>you forgot some vital ones
>
>On Thu, Feb 03, 2005 at 02:43:50AM -0800, Ashley Yakeley wrote:
>  
>
>>* POSIX time
>>
>>Can do accurate calculations on calendar times.
>>Can store UTC times reliably.
>>Cannot store TAI times reliably.
>>Broken for all leap seconds.
>>    
>>
>cannot represent durations
>undefined before 1970, muddy definition in the future.
>
>  
>
>>* TAI time with limited leap-second table
>>
>>Can do accurate calculations on calendar times.
>>Cannot store UTC times reliably.
>>Can store TAI times reliably.
>>Broken for leap seconds after table runs out.
>>    
>>
>can represent durations
>defined for all history and future
>
>  
>
>>Which of these is better?
>>    
>>
>
>TAI is clearly superior.
>        John
>
>  
>