public interface UniversalTime extends UnixTime
Defines a time point respective coordinate on the universal timeline as the count of seconds relative to UTC epoch [19720101T00:00:00Z] in the UTCtimezone (Greenwich meridian) and a nanosecond as part of last second.
The abbreviation "UTC" stands for the term
"Corrected Universal Time". This term relates to the timezone
UTC+00:00 as reference for all timestamps. This API uses as
measurement system a combination of seconds (hold in a longprimitive)
and nanoseconds as fraction of last second (hold in an intprimitive).
In such defined system all time points of type TimePoint
can be directly compared with each other which implement this interface.
The time of the technical introduction of UTC in radio signals on the
date 19720101 is determined by Time4J as UTCepoch. Before this epoch
the second is just the 86400th part of a mean solar day. After the
UTCepoch the atomic time is valid with the new definition of the
second as SIsecond based on the count of periods in a caesium atom
at a given frequency transition.
Generally the rules of univeral time are those of the gregorian calendar  with the exception of leapseconds. UTC and ISO8601 (for the representation) take into account leapseconds which were introduced in order to always keep the difference between an atomic clock and the mean solar time UT1 within the range of 0.9 seconds. The solar time UT1 is a mean average time due to the anomalies associated with the irregular rotation of earth around the own axis where every day consists of 86400 seconds having a variable length. Therefore these seconds are no SIseconds. This API reads UTCleapseconds from a table and defines the universal time in SIseconds since the begin of UTCepoch [19720101T00:00:00Z] including a nanosecond part (mostly only precise to milliseconds). Taking out the leapseconds and by transforming to the POSIXepoch 19700101 yields the POSIXtime where every minute always have 60 seconds (on the base of one calendar day equal to 86400 seconds).
The UTCstandard defined so far was officially introduced on the date 19720101. Befor this UTCepoch there are no leapseconds. The consequence is that Time4J interpretes all historical timestamps before 1972 as UT1time  with reference to mean solar day on Greenwich meridian. Correspondingly the definiton of the second changes with the begin of UTCepoch to atomic based time. The definiton of the calendar day changes, too. For all UT1timestamps the calendar day is identical with the mean solar day which can yield the true solar day using the equation of time (astronomical formula). But with start of UTC a calendar day consists of 86400 SIseconds, in rare cases of 86401 or (until now only theoretical) 86399 SIseconds. This definition of the calendar day is already now no longer exact equal to the mean solar day. The leapseconds only guarantee an approximation of the calendar day to the mean solar day such that the difference will never go beyond 0.9 seconds.
There is a debate initiated by USA to abolish leapseconds. If this might happen then Time4J would start a new section on the universal timeline after UT1 and UTC  with a probably new name. The new section will surely be based on SIseconds but indeed stop to count any leapseconds. This interface would then mutate to a pure atomic scale without any reference to the mean solar day. The deviation of the atomic day from the mean solar day is in year 2013 already about 25 SIseconds. The ITUconference in January 2012 just decided to postpone the decision about the proposal to abolish leapseconds first in year 2015. ITU is an international organization for controlling the radio signals and telecommunication standards. Currently ITU manages the UTC standard, too. Time4J stores timestamps using the concept of this interface as followed:
Section  Name  Second definition  Details 

before 19720101T00:00:00Z  UT1  mean solar second  A mean solar day corresponds to always 86400 seconds with variable length. 
19720101T00:00:00Z until day X  UTC (with leapseconds)  SIsecond based on atomic clocks  A calendar day consists in most cases of 86400 SIseconds sometimes also of 86401 or 86399 SIseconds. The mechanism of leapseconds is responsible for keeping the difference between the calendar day and the mean solar day within the range of 0.9 SIseconds. Due to the impossibility to make longtermpredictions about the earth rotation the day X is about 6 months after current date or last leapsecond in the future. The institute IERS is responsible for announcing leapseconds around 6 months in advance. A second precision is not given for any kind of time calculations if the calculation includes the future further than 6 months. 
after day X  IT ??? (International Time ???  without leapseconds)  SIsecond based on atomic clocks  Future leapseconds are no longer defined here. Consequently the calendar day based on 86400 SIseconds will increasingly deviate from the mean solar day. 
If leapseconds in Time4J are switched off per configuration then UTC will practically mutate to POSIX with the exception of the different epoch date (two years between epochs). Calculations of time deltas in SIseconds and fractional seconds will get a small error after UTCepoch which can normally be ignored in standard business usecases (for example banks do not care about seconds when calculating daybased interest rates).
Arguments for keeping leapseconds alive:
UniversalTime
uses UTC as universal time scale. Simultaneously
the limitation to leapseconds on the section from 1972 and later takes
into account that before this epoch there is no precision in seconds due
to technical and practical reasons. Even today nanosecond precision is
not realistic with all kinds of computer clocks or the NTPprotocol and
only exists here for database support (SQLTIMESTAMPsupport, databases
often generate nanotimestamps as primary keys by help of randombased
numbers or a simple numerical counter). But after 1972 it is also valid
to say that for example relative inaccurate computer clocks can adapted
manually to UTCtime and are sufficiently sensible for leapseconds near
leapsecond events if it is just about second precision. Further links for definition of UTC:
LeapSeconds
Modifier and Type  Method and Description 

long 
getElapsedTime(TimeScale scale)
Represents this timestamp as elpased seconds on given time scale.

int 
getNanosecond(TimeScale scale)
Represents the nanosecond part on the given time scale.

boolean 
isLeapSecond()
Queries if this time point is within a positive leapsecond.

getNanosecond, getPosixTime
long getElapsedTime(TimeScale scale)
Represents this timestamp as elpased seconds on given time scale.
The method getPosixTime()
inherited from UnixTime
is equivalent to getElapsedTime(TimeScale.POSIX)
and relates
to the UNIXepoch 19700101. The time scale UTC starts two years
later however and also counts leapseconds.
scale
 time scale referenceIllegalArgumentException
 if this instance is out of range
for given time scaleint getNanosecond(TimeScale scale)
Represents the nanosecond part on the given time scale.
The method with the same name and without argument inherited from
super interface UnixTime
is identical to this method if the
time scale is either POSIX
or UTC
.
scale
 time scale referenceIllegalArgumentException
 if this instance is out of range
for given time scaleboolean isLeapSecond()
Queries if this time point is within a positive leapsecond.
If the support for UTCleapseconds is switched off per configuration
then this method will always yield false
.
true
if this instance represents a positive
leap second else false
LeapSeconds.isEnabled()
Copyright © 2014–2019. All rights reserved.