[LEAPSECS] Java: ThreeTen/JSR-310

[Stephen Colebourne]

On 28 January 2011 20:42, Tom Van Baak <tvb at leapsecond.com> wrote:

>> As I said before, having looked at the subject, I now strongly believe

>> that any alteration to the current scheme of occasional leap-seconds

>> would be a serious mistake with large consequences.

>

> Can you explain the above comment a little more?


Viewed from afar, leap seconds appear to be a really stupid idea. A
gross complication in the passage of time, that so few people care
about, yet can cause such nasty effects such as time going backwards.

Based on 10 years experience of Joda-Time, I can see what API users
understand and what they don't. Variable length months (June 30, July
31) are well understood, yet occasionally cause problems. Leap days
are understood, yet users often forget them or complain when they
occur. Time-zones are frequently forgotten, and many don't understand
them or why 01:30 doesn't exist. Leap seconds are just not even
considered.

Asking users of dates and times to cope with variable length months,
leap days and time-zones is more complexity than many can currently
handle. Expecting them to understand about leap seconds is a step too
far. (Try asking your business analyst what the software should do on
a leap-day and they'll tell you, they can probably tell you what to do
at a time-zone change if they think hard, but they'll never know how
to handle a leap second)

But...

The Earth does not rotate at 86400 SI seconds per day. Once I
internalised that fact properly, my requirements were clear. For the
main API days must have 86400 "seconds" (not necessarily SI) and days
were more important than seconds.

I came to the conclusion that I, as I believe my users do, care far
more about days formed of 24 hours, 60 minutes and 60 "seconds" far
more than any leap second notion. Thus, no matter what, the Sun must
peak at midday and it be night at midnight, with adjustments to ensure
that based on time-zones. Since stopping leap seconds breaks that
basic principle, it became unacceptable.

Moerover, amongst experts, leap seconds are well understood. Removing
them, or changing the scheme in some way, simply causes yet another
form of historical anomaly in the time-line to deal with when
considering the past. That anomaly would be worse than any "cure".
Plus, GPS, time-signals, and OSs all have some form of dealing with
leap seconds at his point. The cost to change is far too high.

Beyond that, implementing leap seconds turned out to not be that hard.
You simply separate into three
- TAI - simple incrementing number that is well-defined (although
clearly not everyone here will agree with that). TAI can be used into
the far future and the far past
- UTC - the current world standard with leap seconds (picked up from
the zoneinfo data). UTC cannot be used especially safely for the
future.
- 86400 - what everyone really wants

Given that, I needed a way for time to always move forwards, and to
resolve UTC to 86400. Solution UTC-SLS.

Thus my conversion is based around the primary importance of the day,
and its subdivisions of hour, minute and second making a fixed 86400
pattern. Leap seconds provide an easy to understand way to cope with
the detailed scientific requirement that is easy enough to manage if
dealt with separately with a simple clear mapping like UTC-SLS.

In other words, once I had fully understood leap seconds and the
variation of the Earth's day, leap seconds were an obvious solution to
the Earth problem and UTC-SLS was an obvious solution to the human
problem. The two go hand in hand.

The only other approach that makes sense to me is to define the
human-second as 1/86400th of a day, and rename to SI second to the tic
or some other name (its easier to get scientists to rename their units
than the general public). But in my view, the mapping between the tic
and the human-second is harder with this approach than using leap
seconds and UTC-SLS.

Thus, I believe there is more chance of getting the computing industry
to adopt leap seconds than anything new, especially with a simple
conversion like UTC-SLS which is quite frankly ideal.

BTW, I have a physics degree, so come from a science background,
although I remember very little of it. These days my primary concern
is working out what "the masses" need and designing APIs that they can
successfully use easily and without error.

Stephen