System.Time.Clock Design Issues

Keean Schupke k.schupke at
Thu Feb 3 08:37:41 EST 2005

Keean Schupke wrote:

> Ashley Yakeley wrote:
>> In summary:
>> Using TAI with a limited leap-second table is trading a simple kind 
>> of brokenness (all leap seconds) for a complicated kind (future leap 
>> seconds after some date).
>> Getting rid of it all and using CalendarTime means slower clock 
>> retrieval and calculations as well as time-zone uncertainty.
>> What would you recommend?
> I dont see why a calinder time is slower... UTC would be just another 
> instance of the
> Calendar class, and you can use specialised fast instances to do the 
> calculations (call
> a C library)

Infact thinking about this POSIX time could be just another instance of 
the Calendar class...
I would keep "system" time to TAI and in an SI unit only. Perhaps it 
makes more sense to split
the class in two, so you treat hours of the day differently to days of 
the year...

If your platform provides POSIX time the POSIX instance of the Calendar 
class could call
OS functions directly rather than converting from "system-time".

Calendars could be instances of Ord and Num, making date/time 
calculations in any time system

I am imagining system time being a simple (pico)seconds counter  (TAI)  
to be used for  accurate
timing (like fire thrusters 312,434 seconds after entering orbit)...


More information about the Libraries mailing list