System.Time.Clock Design Issues
k.schupke at imperial.ac.uk
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
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