Approach to leap second discussion

From: Ed Davies <ls_at_edavies.nildram.co.uk>
Date: Sun, 22 Jan 2006 20:49:30 +0000

The way I think exploration in this group should be going is to
seriously examine what engineering steps can be taken to deal with
leap seconds properly. This means looking at changes to Posix and
NTP, new protocols for disseminating leap second information,
new APIs for accessing clock information with different properties
and so on. Also, possible changes to leap second scheduling to
give longer notice. If, taking all of those together, we find that
there are important use cases which cannot be covered then we've
made a good case for scrapping leap seconds.

The obverse is to look at the use cases (e.g., in astronomy and
navigation) which require UT1 (or other Earth orientation information)
and look at ways for them to recover that from an atomic timescale. If
there are, again, any important use cases which cannot be covered then
there's a good case for keeping leap seconds.

My suspicion is that actually all cases are reasonably easy to deal
with with only a little care. In that case, it becomes an engineering
trade-off - which of keeping or scrapping leap seconds causes the
least hassle.

Starting from a clean slate, I'd guess that doing without leap seconds
would be the right answer - at least now, though probably three decades
ago the right decision was made for that time. On the other hand,
they're here now and I'm far from sure that change would be worthwhile
and we don't know for sure what the balance will be in another three
decades.

What isn't helpful is to have two groups each starting from an
assumption or even definition that one or other answer is right
repeatedly shouting past each other - particularly using arguments
which are tricky to the point of dishonesty, blunt rudeness,
personal attacks and so on.

I hope we can all continue this discussion in a more positive
manner.

Ed.
Received on Sun Jan 22 2006 - 12:50:25 PST