> I noted this in the draft communities report:
>
> [[
> Currently, the discussion has stalled again. The leap seconds
> issue is something of a sticking point, and there are some
> implementability question marks over other parts of the API.
> Contribution to (any aspect of) the discussion is welcomed.
> ]]
>
> As a process meta-issue, I would ask: is there an approach
> we can adopt
> that allows the concerns about implementability of leap-seconds to be
> deferred to a later stage, to the maximum extent possible.
>
> My simple-minded view is that an approach based on an
> underlying value a
> pair of values (e.g. days,picoseconds) would allow systems
> implemented
> without concern for leap seconds to be adequate for a good number of
> practical applications. And systems that do know about leap
> seconds can do a better job.
I don't think this solves the problem (but I might be wrong).
We have no problem with doing calculations on TAI time, and doing
conversions between TAI and UTC. This has been demonstrated - recently
by Juanma Barranquero's library posted to the Haskell list, and I also
hacked up a simple TAI library a while ago (though not nearly as
complete as Juanma's).
The problem is how to get access to TAI time on Unix systems (and indeed
other OSs, probably). Unix systems provide something called time_t,
which is a timescale that doesn't include leap seconds. Strange things
happen on a Unix system when a leap second occurs: the proper way (it
seems) to deal with leap seconds is to slow down the system clock a bit
until the actual time catches up with time_t again. The point is that
if you only have access to time_t, and you don't know what the system is
doing with leap seconds, you can't tell what the time is.
I'm sure that most people don't care about this (I certainly don't :-).
Personally I think it's ok to have a library that "does its best" to
give you the correct TAI time, with documented caveats. IIRC, this is
where we got stuck.
Also, I believe the proposed System.Time library had some functionality
which is difficult to implement on Unix systems (eg. a function to
convert a timezone name to a GMT offset isn't available AFAIK).
Cheers,
Simon
