[LEAPSECS] Do lawyers care (know) about leap seconds?

Stephen Colebourne scolebourne at joda.org
Wed Oct 1 09:33:03 EDT 2014


On 1 October 2014 13:02, Greg Hennessy <greg.hennessy at cox.net> wrote:
>> But the basic point still remains: If you have to sugar coat the actual
>> standard
>> with a fake standard to paper-over people’s inability to deal with the
>> actual
>> standard, this suggests that you have the wrong actual standard.
>
> I would agree that we have the wrong actual standard. We've had leap
> seconds since 1972, but POSIX still mandates we ignore the leap seconds
> in places. It would be nice if the standards and the practices match.
> Some people want to change the standards, and others want to change
> the practices.

It doesn't work well because there are two different requirements in
tension - the desire to work in terms of solar days and the desire to
define an absolute second. Like it or not, UTC itself is a perfectly
valid mechanism to bridge the gap between the two.

So, why do engineers not adopt UTC properly? I posit it is because the
leap second simply is generally not important enough to care about at
the business level, thus there is no reason for the engineers to care.
Where the business does care, such as in TV/finance/web, the
requirements are driven from the business and engineers have no choice
but to care.

The problem is that UTC and its transmission as a broadcast time scale
only covers part of the need, and without the rest it tends to fail.
We also need

- reliable transmission. It is absurd that we cannot get all NTP
servers to send out the leap second info at the right time and with
minimal/no human intervention. A central web service of leap second
data wouldn;t be that hard...

- a clear smoothing/smearing standard, mapping from UTC (with leap
seconds) to smoothed-UTC (86400 secs per day, no leap seconds). This
could be UTC-SLS, Google smear or something else, so long as there is
a clear well-defined standard.

- operating system support for the smoothing/smearing standard. An
application/language can then choose whether to use UTC (and handle
leaps) or smoothed-UTC (when the business doesn't care about that kind
of detail.


Abolishing leap seconds is another approach, but it works by putting a
head in the sand and ignoring the underlying tension with solar days.
And my big fear is that some more religiously minded countries might
choose to carry on using leap seconds because of the higher value they
place on the Sun in timekeeping. Having two countries permanently
differ in current time by a few seconds would cause engineers far more
problems than leap seconds do today.

Stephen


More information about the LEAPSECS mailing list