[LEAPSECS] Instant (86400 second Java class) [was Java:ThreeTen/JSR-310]

[Tom Van Baak]

> smoothing for that. (As I've said before, stopping leap seconds now

> isn't helpful as it adds yet another mapping/complication, rather than

> removing one)


This I don't understand. As far as UTC is concerned, isn't the
proposal to stop leap seconds effectively the same as IERS
just not sending out email anymore about when the next leap
second will occur? No java or OS code needs to change.

For example, we had an amazing 7 year stretch from 1999 to
2006 without leap seconds. It was, for all the hardware and
software clocks we're talking about here, as if UTC was a
time scale without leap seconds. UTC was smooth; each day
had 86400 seconds. No one had flip leap-second-pending
switches or manually edit all those leap second tables and
config files.

You don't provide a UT1 method in your class; your class is
dependent on the underlying host OS to provide UTC -- so
I'm curious why there are mapping or coding issues were
leap seconds to go away someday?

/tvb