System.Time.Clock Design Issues

[Keean Schupke]

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
easy.

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)...

    Keean.