[LEAPSECS] USWP7A docs for 2013 September meetings

[Stephen Colebourne]

On 14 August 2013 07:41, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> As I said:  For anything like what you propose to be viable, the

> leap seconds must to be scheduled 5-10 years in advance, so that

> the certification can be done on the OS level rather than at the

> application level.


Having spent the last 10 years or so designing time APIs for the
world's most popular enterprise language Java, I can also say that it
is not a simple matter of updating software.


>From the high level end, the problem is that leap seconds are not

important enough to be included in business logic definitions.
Software at this level is typically business-driven, often by someone
specifically defining what the software should do. Those requirements
will expect the software to handle different length months and leap
years without saying anything much. If pushed, the requirements might
define what happens around a DST change. However, they will pretty
much never say anything about leap seconds.

This also impacts on developers. Most developers will write code
assuming that there are always 60 seconds in a minute. Even if you
give those developers the nicest possible library API with very
convenient methods, many developers will still hack in something that
involves multiplication or division by 60, because hacking is in the
developer mindset. Thus there really isn't anything that a high level
library API writer can do to support leap seconds. 99% of developers
expect a method getSecondOfMinute() to only ever return 0 to 59, and
they will certainly never expect or test for 60, resulting in bugs.

It is therefore essential to prevent leap seconds from being exposed
to 99% of developers.

The easiest way to eliminte them is to remove them. However, I differ
from Poul-Henning however in that I don't find it palatable to ignore
the fact that humans define days by the Sun. We all know that time
doesn't follow that definition exactly, but over the long term, the
definition has always stood and has real meaning to non-technical
humans.

I do agree that the only hope of saving leap-seconds is announcing
them irrecovably in advance. However, I believe that a formal
mechanism for smoothing over the leap second, like UTC-SLS or Googles
smear, is also needed to make that approach work. It is the smoothing
that is the missing piece to allow accurate clocks to be converted to
ones human's actually want.

The approach of smothing any leap is what Java version 8 will be
defined using (which is a definition that also handles abolition of
leaps, should that occur).

Stephen