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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
