RE: Time Library Organisation
On 26 January 2005 08:43, Ashley Yakeley wrote:
This is one way the time libraries might be organised. I think the functionality splits cleanly into two separate modules.
"Time" module (System.Time? System.DateTime.Time?)
* TAI/UTC arithmetic and conversions, leap-second tables
* possibly UT1 types and conversions, Julian days and dates
* getting the current time
"Date" module (System.Date? System.DateTime.Date?) importing Time module
* time zones
* getting the locale time zone
* converting times to "calendrical" format, Gregorian and possibly also Julian
* calendrical arithmetic e.g. one month after March 31st
* possibly "incomplete dates" e.g. "May 1" for all years
* parsing and showing dates and times
Looks fine to me. Maybe System.Time.Clock and System.Time.Calendar? Cheers, Simon
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.
Hi all, I found the scheme library proposal for time very interesting to read -- it is also recent and gives pointers for implementing it. http://download.plt-scheme.org/scheme/docs/html/srfi/srfi-19.html -- Daan.
Daan Leijen
(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
You can't have gettimeofday() returning UTC and libtai returning TAI at the same time, because they return the same thing. This is the implementation from libtai: void taia_now(t) struct taia *t; { struct timeval now; gettimeofday(&now,(struct timezone *) 0); t->sec.x = 4611686018427387914ULL + (uint64) now.tv_sec; t->nano = 1000 * now.tv_usec + 500; t->atto = 0; } and documentation: NOTES This implementation of tai_now assumes that the struct timeval returned from gettimeofday represents the number of TAI seconds since 1970-01-01 00:00:10 TAI. DJB (the author of libtai) disagrees with POSIX about what gettimeofday should return, and assumes that it actually returns what he wishes it returned.
(2) We can convert TAI to UTC (and back) up to half a year in the future.
Assuming that during the half of the year: - the Haskell compiler has been updated - and released - and installed where the given software will be compiled - and the software has actually been recompiled - and the program has been restarted (if it's running as a daemon) Otherwise the process will disagree with the rest of the system by one second. Actually software which assumes that gettimeofday() returns TAI already disagree with software which assumes that it returns UTC, by some tens of seconds (depending on how they assume the Epoch). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
You can't have gettimeofday() returning UTC and libtai returning TAI at the same time, because they return the same thing. This is the implementation from libtai:
[snip]
DJB (the author of libtai) disagrees with POSIX about what gettimeofday should return, and assumes that it actually returns what he wishes it returned.
Wow, that is terrible! Well, we can not fix libraries. If libtai is that broken, we can just as well do it ourselves: if we assume that we can convert a current UTC time to TAI, we can calculate the TAI time at the start of the program and use time_t to keep track of the TAI delta -- here we take advantage of the time_t bug which is not adjusted for leap seconds! About the assumption of converting current UTC to TAI:
(2) We can convert TAI to UTC (and back) up to half a year in the future.
Assuming that during the half of the year: - the Haskell compiler has been updated - and released - and installed where the given software will be compiled - and the software has actually been recompiled - and the program has been restarted (if it's running as a daemon)
Well, I would think that someone (?) distributes a table with leap seconds that is inspected by the library. We could maybe even install it as a separate package. I think the key distinction between TAI and UTC (or calendars) is that TAI is great for measuring time delta's, while UTC (and other calendars) are good for marking specific "human times" -- and sometimes we have multiple markers for the same time (when a leap second occurs). Given that TAI is best suited for time delta's, it might be good to define "monotonic" time like in scheme[1]. This is just SI-seconds, like TAI, but we leave the epoch unspecified. As such, the current "time_t" behaviour of unix (unadjusted for leap seconds) implements this. This means that monotonic time can do most of what TAI can do, but we can always provide it accurately. -- Daan. [1] http://download.plt-scheme.org/scheme/docs/html/srfi/srfi-19.html
In article <87mzuu96x4.fsf@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk
DJB (the author of libtai) disagrees with POSIX about what gettimeofday should return, and assumes that it actually returns what he wishes it returned.
It seems what should have been done was to create a modification to the kernel that allows the hardware clock to run on TAI but have gettimeofday return broken time as per POSIX, and have some other function to return TAI time. Perhaps someone's done this.
(2) We can convert TAI to UTC (and back) up to half a year in the future.
Assuming that during the half of the year: - the Haskell compiler has been updated - and released - and installed where the given software will be compiled - and the software has actually been recompiled - and the program has been restarted (if it's running as a daemon)
Of course, even if the available clock uses broken POSIX UTC time, users might still want a leap-second table to convert to TAI. -- Ashley Yakeley, Seattle WA
In article <87mzuu96x4.fsf@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk
DJB (the author of libtai) disagrees with POSIX about what gettimeofday should return, and assumes that it actually returns what he wishes it returned.
It seems what should have been done was to create a patch to the kernel that allows the hardware clock to run on TAI but have gettimeofday return broken time as per POSIX, and have some other function to return TAI time. Perhaps someone's done this.
(2) We can convert TAI to UTC (and back) up to half a year in the future.
Assuming that during the half of the year: - the Haskell compiler has been updated - and released - and installed where the given software will be compiled - and the software has actually been recompiled - and the program has been restarted (if it's running as a daemon)
Of course, even if the available clock uses broken POSIX UTC time, users might still want a leap-second table to convert to TAI. -- Ashley Yakeley, Seattle WA
Ashley Yakeley
It seems what should have been done was to create a patch to the kernel that allows the hardware clock to run on TAI but have gettimeofday return broken time as per POSIX, and have some other function to return TAI time. Perhaps someone's done this.
I tried to find out, with no success. Anybody? I'm about to reinstall my Linux laptop after a disk crash, so I could try to do this. It also appears that support is needed in NTP, although I'm not sure why.
Of course, even if the available clock uses broken POSIX UTC time, users might still want a leap-second table to convert to TAI.
I don't think UTC is broken, only POSIX and its time_t representation which quietly moves pushes the epoch a bit forward every leap second. UTC is the calendar specification, and not a counter, right? (I.e. UTC specifies the second "1998-12-30T23:59:60" as a perfectly good, normal second, while the corresponding POSIX time_t (and NTP second) is ambigous, and could mean the next (or previous?) second as well.) Am I the only one who feels that a calendar, unlike a clock, should specify particular time units (e.g. a particular day, hour, or second), and not infinitesimal points in time? So I would distinguish between the day "1998-12-30" and the hour "1998-12-30T00", for instance. I think this fits better with the applications I can imagine, but perhaps I'm a bit short on imagination? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (5)
-
Ashley Yakeley -
Daan Leijen -
Ketil Malde -
Marcin 'Qrczak' Kowalczyk -
Simon Marlow