On 2005-01-27, Ashley Yakeley wrote:

In article <3429668D0E777A499EE74A7952C382D1030DE110@EUR-MSG-01.europe.corp.microso ft.com>, "Simon Marlow" wrote:

...

I like the idea of having a single notion of absolute time, which is independent of TAI or UTC time. You can do arithmetic on absolute time (add/subtract absolute units of time, find absolute time differences), and convert to/from TAI and UTC.

My library happens to keep absolute time as TAI seconds since the epoch, but it doesn't have to. A representation using (days,ticks) sounds like it might be hard to do arithmetic on, though.

I think your ClockTime is a sensible way to represent absolute time for TAI. But we also need something that represents (for instance) "2008-08-03 11:00:00 UTC" even though we don't know what precise TAI time that will be. For this I would consider using a (days,ticks) pair: it allows you to do arithmetic such as "5 UTC days later" and end up with the expected answer even when there are intervening leap seconds.

This seems reasonable at first glance. What happens when the rules for leap years change though? (Okay, so that's really planning ahead...) I would in fact reify TAI for purposes of exchange with other systems. "Now, who wants to think about timekeeping in domains where SR and GR effects matter?" -- Aaron Denney -><-