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