RE: Implementability and Time.TimeDiff
On reflection, I think this is too precise information to be accessible from a portable library. In particular, I'm not sure it's possible to correctly implement a TAI-based time system on most Linux distributions without modification (I was rather shocked to discover this...),
Oh dear. Could you explain why it can't be implemented? What does the existing libtai do - is it incorrect? The glibc docs say: - Data Type: time_t This is the data type used to represent simple time. Sometimes, it also represents an elapsed time. When interpreted as a calendar time value, it represents the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time. (This calendar time is sometimes referred to as the "epoch".) POSIX requires that this count not include leap seconds, but on some systems this count includes leap seconds if you set `TZ' to certain values (*note TZ Variable::). but it doesn't elaborate on which TZ values cause leap seconds to be included in time_t, so I can imagine that would cause difficulties. Cheers, Simon
On Mon, Jun 23, 2003 at 10:44:14AM +0100, Simon Marlow wrote:
On reflection, I think this is too precise information to be accessible from a portable library. In particular, I'm not sure it's possible to correctly implement a TAI-based time system on most Linux distributions without modification (I was rather shocked to discover this...),
Oh dear. Could you explain why it can't be implemented? What does the existing libtai do - is it incorrect?
libtai is correct, but relies on an NTP client that behaves differently from standard ones. There really doesn't seem to be enough information.
The glibc docs say:
- Data Type: time_t This is the data type used to represent simple time. Sometimes, it also represents an elapsed time. When interpreted as a calendar time value, it represents the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time. (This calendar time is sometimes referred to as the "epoch".) POSIX requires that this count not include leap seconds, but on some systems this count includes leap seconds if you set `TZ' to certain values (*note TZ Variable::).
but it doesn't elaborate on which TZ values cause leap seconds to be included in time_t, so I can imagine that would cause difficulties.
Standard glibc comes with two variants of each timezone, 'posix/...' and 'right/...', which behave differently wrt leap seconds. (The posix variant closes its eyes and pretends that leap seconds don't exist in the time_t type, which is represented as an integer type.) The standard setting of the NTP client, which is what you use if you want accurate time, resets the time_t variable backwards by 1 at a leap second; it does this with a special system call to the kernel (adjtimex), but there doesn't seem to be any way to get the information back out from the kernel (again, by default in most installations). (You might be able to get the information back with another adjtimex system call, but it certainly won't be portable outside of Linux systems.) This is a really bone-headed approach, but it seems to be what we have to deal with. I think giving correct time is a matter for the operating system, and Haskell libraries should use what they're given... What do the BSDs do? Peace, Dylan
participants (2)
-
Dylan Thurston -
Simon Marlow