RE: System.Time.Clock Design Issues
On 03 February 2005 10:44, Ashley Yakeley wrote:
OK, so we have
* POSIX time
Can do accurate calculations on calendar times. Can store UTC times reliably. Cannot store TAI times reliably. Broken for all leap seconds.
* 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.
Which of these is better?
The point is that everything you can do with a POSIX time you can also do with a calendar time, which we need anyway. So why have a POSIX time too? Cheers, Simon
In article
<3429668D0E777A499EE74A7952C382D1031907F4@EUR-MSG-01.europe.corp.microso
ft.com>,
"Simon Marlow"
On 03 February 2005 10:44, Ashley Yakeley wrote:
OK, so we have
* POSIX time
Can do accurate calculations on calendar times. Can store UTC times reliably. Cannot store TAI times reliably. Broken for all leap seconds.
* 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.
Which of these is better?
The point is that everything you can do with a POSIX time you can also do with a calendar time, which we need anyway. So why have a POSIX time too?
Sure, we could get rid of it entirely and rely on CalendarTime everywhere. This is the trade-off I see: * POSIX time not already necessary fast retrieval from system clock fast calculation of time differences and offsets independent of time-zone * Structured calendar time already necessary anyway slow retrieval from system clock slow calculation of time differences and offsets may be dependent on time zone 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? -- Ashley Yakeley, Seattle WA
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) Keean.
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.
participants (3)
-
Ashley Yakeley -
Keean Schupke -
Simon Marlow