Time Library Organisation

[Daan Leijen]

Hi all,

I wanted to give a short summary of what has been discussed lately. I 
hope that it can clarify the design space a bit, and give more direction 
to the whole discussion:

---------------------------------------------------------------------
(A) We surely want a notion of absolute time. Clearly this must be TAI. 
The nice thing about absolute time is that we can manipulate it 
algebraicly, substracting and adding numbers. This is great for sending 
spaceships to planets.

(B) We need calendars: these are time markers that humans like to talk 
about. A particularly important calendar is UTC! (I think most other 
calendars can be implemented on top of UTC?) Operations on UTC are much 
harder since things as the next day etc. are difficult in certain 
situations. However, calendars are great for specifying mortgage dates 
and appointments.

Let's clearly separate (A) and (B) from each other during future 
discussions.

---------------------------------------------------------------------
There are two issues to be addressed: (1) can we implement A or B? and 
(2) can we convert between the two.

(1) Implementation of TAI: On windows, the "FILETIME" is defined as 100 
nano-second intervals after some epoch (1 Jan 1601 UTC). So, there is 
some basic atomic time available. On unix's we can use libtai.
Implementation of UTC: On windows, the "SYSTEMTIME" supposedly gives 
UTC, on unix I believe that "gettimeofday" and friends supposedly give UTC

So, the good news is that we can support both (A) and (B) on most 
systems. Furthermore, we can do a pretty good approximation of either 
one if the OS is broken (and a language should not fix the OS!)

(2) We can convert TAI to UTC (and back) up to half a year in the 
future. So, the banks should use UTC internally, and spaceships TAI, but 
you can not have both in general (or better, in the future :-)
This also makes clear that the library should provide both (A) and (B), 
and can not get away with just (A) or (B).

---------------------------------------------------------------------
Here are some concrete ideas about the design of a library for (A) and 
(B) -- actually, I think that Simon has already done most of this!

(A) The absolute time should be held in an Integer that holds pico 
SI-seconds (or something as precise). The number 0 represents the epoch: 
a calendar date (UTC) where TAI says the counter started running (when 
is that actually?). Negative numbers are times before that date, 
positive numbers are times after that date. Of course, most TAI 
computations will be relative to each other, where the epoch doesn't 
matter at all -- it only matters for conversions to calendars like UTC.
(btw. this also means that for almost any application that uses TAI, we
can approximate it reliably using UTC without leap seconds)

(B) The UTC time should probably be held in a big record with fields for 
years, months, days, etc. To provide for leap seconds, functions must be
provided for roll-overs: ie. some minutes will have 60 seconds. 
Futhermore, there is a function that converts between TAI for any date 
up to half a year in the future (after which it becomes unreliable :-) 
Another design decision could be to hold UTC time too in a big Integer 
of pico UTC-seconds and use a few formulas to convert to/from a 
year/month/day.. record. A problem might come up with leap seconds 
though (hmmm, is that true?)

(C) And of course, someone should think about other calendars than UTC: 
can we always derive those from UTC or TAI?	However, a first *concrete* 
library for just TAI and UTC (+time zones) would already be great.


-- Daan.