On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote:
> POSIX in the past deferred to WG14 (the ISO C committee) because
> that's
> where time_t came from.
>
> WG14 is willing in principle to make changes to time_t, up to and
> including
> completely replacing it by something else. *BUT* it needs a
> complete and
> consistent proposal and, preferably, experience with it.
>
> Any proposal has got to deal with a whole load of issues, many of
> which
> haven't been properly documented. For example, it should be
> possible to add
> and subtract times and intervals (e.g. "what time is 14 months and
> 87 days
> from now?").
Well, I can explain what I did in Haskell, at least.
In the Haskell time library, I represent UTC time by what seemed to
me the simplest possible correct type. This is a record containing an
integer to represent day number (as MJD), and a fixed-point decimal
(picosecond resolution) to represent seconds since midnight. The
allowed range for this is 0 to 86400.999999999999. Thus, time during
a leap second can at least be unambiguously represented. However, my
call to get the current UTC time relies on gettimeofday, so it is
unavoidably off by up to a second during a leap-second insertion.
The majority of users of my library do not want to know about TAI or
leap-seconds, but cannot tolerate unexpected off-by-one-second
issues. Therefore I have the concept of "nominal UTC difference". For
instance, between 2005-12-31 23:00 UTC and 2006-01-01 01:00 UTC there
were two hours and one second of time, but only two hours of nominal
UTC time.
It's incumbent upon anyone using "nominal UTC difference" that they
understand its flaw in representing time, if they care. This is easy
in Haskell, since it has a different type from the type I provide for
real time difference, and these cannot substitute for each other.
--
Ashley Yakeley
Received on Wed Dec 27 2006 - 02:52:35 PST