# [ntp:questions] Leap second to be introduced in June

Charles Elliott elliott.ch at comcast.net
Tue Jan 20 15:42:52 UTC 2015

```Programmers universally compute the number of days between two dates by
determining the seconds of the two dates (by using a function such as
getTimeInMillis() for each date), computing the difference in seconds
between the two dates, and dividing the difference by 86,400.

I proved this to myself by performing the following experiment with three of
Java's date classes, GregorianCalendar, Date, and ZonedDateTime.  In
pseudocode:

For year = 1997 to 2015
Date1 = year, month =1, day =1, hour = minute = second =0
Date2 = year+1, month =1, day =1, hour = minute = second =0
Duration = Date2 - Date1 (in seconds)
Print Date1, Date2, Duration

Date1 = 1997, month =1, day =1, hour = minute = second =0
Date2 = Date1 + 31_536_000 * 18 + 4 * 86_400 //Add 18 yrs (in secs) + 4 days
for leap years
Print Date1, Date2

For each of Java's date classes, the Duration was equal to 31,536,000
seconds (= 365 * 86,400) for all years except leap years, when the duration
was 31,622,400 (=31,536,000 + 86,400) for 366 days.  In the second part,
Date1 = Jan 1, 1997 and Date2, which was equal to Date1 plus 18 years of
31,536,000 seconds per year + 4 leap days, equaled Jan 1, 2015.

But we know that the duration in seconds of 1997, 1998, 2005, 2008, and 2012
was actually 31,536,001 seconds because each of these years had a leap
second added.  So, why does it work?

Java, at least, is pretty upfront about why it works.  Java describes
ZonedDateTime (and its various cousins Instant, LocalDateTime, and
OffsetDateTime) as implementing a proleptic calendar, where in this case
proleptic means what the data and time would have been in times past if they
implies that the new date/time classes (ZonedDateTime, Instant,
LocalDateTime, and OffsetDateTime) cannot be used for astronomical
calculations.  Why?  Because they won't be correct.  Jan 1, 2015 minus 18
years of 31,536,000 seconds per year - 4 leap days * 86,400 seconds will not
produce the time a computer would have indicated on Jan 1, 1997; instead,
there will be 5 seconds difference for the 5 leap seconds introduced in that
interval.

Oracle's justification for their approach is:

"Given the complexity of accurate timekeeping ..., (the) Java API defines
its own time-scale, the Java Time-Scale.

"The Java Time-Scale divides each calendar day into exactly 86400
subdivisions, known as seconds. These seconds may differ from the SI second.
It closely matches the de facto international civil time scale, the
definition of which changes from time to time.

"The Java Time-Scale has slightly different definitions for different
segments of the time-line, each based on the consensus international time
scale that is used as the basis for civil time. Whenever the
internationally-agreed time scale is modified or replaced, a new segment of
the Java Time-Scale must be defined for it. Each segment must meet these
requirements:

."the Java Time-Scale shall closely match the underlying international civil
time scale;
."the Java Time-Scale shall exactly match the international civil time scale
at noon each day;
."the Java Time-Scale shall have a precisely-defined relationship to the
international civil time scale." (Source: Oracle documentation for the
java.time.Instant class.)

In other words, the only aspect of time that matters to Java is that the
clock, in the present, be perfectly accurate each day at noon.  Thus the
time Java displays and uses will be accurate, and up to spec, if and only if
the user's clock is accurate.

BTW, proleptic can be defined as:

The representation or assumption of a future (past?) act or development as
if presently existing or accomplished.