System.Time.Clock Design Issues
u.stenzel at web.de
Thu Feb 3 10:50:22 EST 2005
"Simon Marlow" <simonmar at microsoft.com> schrieb am 03.02.05 14:47:39:
> On 03 February 2005 13:01, Ashley Yakeley wrote:
> But I agree with the rest of what you say. Basically, providing TAI
> time is problematic because we can't implement it correctly, for future
> times, on systems that only provide POSIX time.
> At this point I'm not sure what is best, I'm still quite disturbed by
> the idea of basing the definition of the Haskell Time library on what is
> basically a mistake in the definition of POSIX :-)
Somehow I fail to see the problem...
Basically we need two different representations of time anyway, a
calendar and something like TAI. The calendar is necessary for everyday
operations, like rolling the date field. This can't be done by adding seconds
to any counter: adding 86400 seconds to get to the next day fails at
least twice a year when switching from/to DST. The "number of seconds"
is necessary for timestamping.
The way I see it, both worlds almost never intersect, the only contact points
are formatting time stamps and converting the current system time to
Suppose we settle for TAI and a separate calendar. We also assume, the
system clock provides TAI, maybe allow an offset to be configured. If the
system time is TAI indeed, all is well. Conversion to calendar time will
always work, because we only convert dates in the past, where leap
seconds are known.
Assume the system provides UTC or POSIX time or something like that.
Then our time stamps will still work, as they are still monotonically increasing.
Nothing fails, only the conversion to calendar time will be off by around 20
seconds. So what? If the modification time of a file is off by some seconds,
probably no one will notice. Same for the current time, most often. If these
few seconds matter, the offset could still be "configured away", and who
cares if it isn't reliable or exact, the system time was broken to begin with.
Therefore, TAI + calendar + (optional) a fixed offset.
What am I missing?
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
More information about the Libraries