[LEAPSECS] Java: ThreeTen/JSR-310

[Stephen Colebourne]

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

>> @Warner, UTC-SLS is simply a clearly written way to reconcile UTC to

>> practical computing/business. I wish it was a recognised standard, but

>> it isn't. That places me in the position of making it a de facto

>> standard unless I receive a suitable alternative proposal. 8 million+

>> Java developers are the market here.

>

> I'm not sure of dates, but it seems Java has been around for

> many years by now. What have these 8 million developers

> and all their apps done until now with respect to UTC?


At the moment, developers use the Date and Calendar APIs, which are
considered of poor quality:
http://download.oracle.com/javase/6/docs/api/java/util/Date.html
http://download.oracle.com/javase/6/docs/api/java/util/Calendar.html

See the Date link for the discussion of leap-seconds.

Basically, the Date class theoretically allows for leap-seconds,
however it provides no mechanism to support it. Were an implementation
to actually support them, the underlying storage (a long millisecond
count from 1970-01-01Z) would fail, and that exposed millisecond value
is very widely used.

Since 1970-01-01Z is before the start of leap-seconds proper, the
whole basis for time in Java is unclear. Plus all days are effectively
considered as 86400 seconds (with no explanation given to map UTC to
86400 seconds). Thus today in Java, leap-seconds are 100% ignored,
with no sensible explanation of how they are handled (at the Java
level - obviously, somewhere there will be code to map the OS clock to
Java, but thats not in my remit).

JSR-310 addresses the definition of 1970-01-01Z (by defining the
TAI-UTC gap as fixed at 10 seconds prior to 1972.

JSR-310 addresses the mapping from UTC to 86400 seconds-per-day using UTC-SLS.

Purists will see both as hacks. But given that 99.9% of users don't
want to think about leap seconds, its a perfectly adequate solution.

I am open to altering the 1000 smoothing factor to another value if it
is written up and reasonably widely circulated. However, I struggle to
see other solutions that allow leap-seconds to be handled as elegantly
as SLS in general, so I don't currently foresee that aspect changing.

JSR-310 also uses what I perceive to be correct terminology, unlike
many others that refer to UTC simply as the same as 86400 second days
at +00:00 offset.

JSR-310 also provides full leap-second support via two separate
classes, designed for specialist users - UTCInstant and TAIInstant.



> Related to that, do you know how your timing requirements

> or proposals jive with all the new OS's that have arrived of

> late (iOS, Android, Windows Mobile 7, etc.)?


JSR-310 is unlikely to have no impact on those OSs immediately.
However, I hope to write a ThreeTen meta-specification which will try
and influence libraries in other languages and operating systems (and
hopefuly SQL too). If the two simplifications above are adopted in
JSR-310, they would then be in the meta-spec, and then might influence
computing more widely. Clearly this is a longer plan, but if it works
then the support of UTC with leap seconds would actually be far
greater than today in computing.

Stephen