Time Libraries Rough Draft

Scott Turner p.turner at computer.org
Thu Feb 10 07:19:44 EST 2005


The MkUTCTime constructor is exposed. Right?

On 2005 February 09 Wednesday 23:46, Ashley Yakeley wrote:
> The idea is that a UTCDiffTime ignores leap seconds, and DiffTime
> doesn't. Thus I can express the concept "three hours UTC" as a
> UTCDiffTime, which will take us from 11:00:00pm to 2:00:00am across a
> leap second. By contrast, "three SI hours" is a fixed period of time,
> and would be 11:00:00pm to 1:59:59am if a leap-second intervenes.

The "three hours UTC" doesn't fit my mental model. Perhaps others find it 
natural.

Compare it to leap days.  Would we support a concept of "three years 
Gregorian" as a count of 1095 days, which would take us from 2003 Jan 1 to 
2006 Jan 1 across the leap day in 2004?  That is,
      2003-Jan-1 `addDays` (3*365) == 2005-Dec-31
      2003-Jan-1 `addDays` (3 * daysPerGregorianYear) == 2006-Jan-1
No, daysPerGregorianYear is obviously problematic.  To do a year-based 
calculation, you would have addYears, as in
      2003-Jan-1 `addYears` 3 == 2006-Jan-1.
UTCDiffTime as a _distinct_ type has the same problem. It is only less obvious 
because leap seconds are less familiar and smaller in magnitude than leap 
days.

The "three hours" concept should be supported directly, perhaps in the 
Calendar module. It shouldn't depend on 1 hour == 3600 seconds.  I don't see 
why a distinction between DiffTime and UTCDiffTime would be beneficial.



More information about the Libraries mailing list