Three actually, and the next leap second is the end of June 2012
(2012-06-30T23:59:60Z). I don't know if this really relates to metrication,
but the current issue of "Metric Today" has about a 1.5 page story on the
proposal to kill the leap second. People may be interested that any further
decision has been deferred to at least 2015:
http://www.nature.com/news/leap-second-granted-extra-time-1.9865
Leap seconds are currently declared with more than five months notice and can
only happen (or not happen) at defined times. Any time-critical software can
and should be defined to accomodate this. GPS time does not incorporate leap
seconds and lags TAI by 19 s. It is widely distributed as a precision time
source. Critical timing applications might do better keeping TAI or GPS time
and computing UTC with a leap second table. Events more than 6 months ahead
would have a 1 s uncertainty in TAI until the potential leap second in the
interval is declared up or down. But really, If you know in mid-January, how
hard is it to recompute events for the end of June?
For less critical applications, the GPS navigational message includes the
current offset to UTC, and the binary code embedded below voice in the WWV
broadcasts carries a leap second flag if there is a leap second at the end of
the current month.
I see no need to completely disconnect time from the sun.
