System.Time.Clock Design Issues

[Marcin 'Qrczak' Kowalczyk]

"Udo Stenzel" <u.stenzel at web.de> writes:

> 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 calendar time.

These "only" points are the problem.

> 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 Haskell programs interpreted the current time and timestamps
differently than all other parts of the system, shifted by 20 seconds,
this is unacceptable.

> 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.

It was not broken.

Yes, it would be better if the system clock ran in TAI, and there was
an automatically updated system-wide leap second table kept current,
and it was supported by the C library and by NTP clients. But it is
not the case.

> Therefore, TAI + calendar + (optional) a fixed offset.
>
> What am I missing?

That you don't know the correct offset.

If a program begins miscalculating the time when it's run 6 months
after the Haskell compiler it was compiled with was been updated,
and thus programs compiled using different versions of the compiler
interpret the same timestamp differently, this makes no sense.

The problem with supporting TAI is that its relation to UTC is not
known far in advance, and it is UTC which is shown to users and
distributed by NTP and manipulated by all other programs. TAI runs
smoothly but it's unimplementable.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/