Instant R
Kenneth
The range of an instant requires the storage of a number larger than a long. To achieve this, the class stores a long representing epoch-seconds and an int representing nanosecond-of-second, which will always be between 0 and 999,999,999. The epoch-seconds are measured from the standard Java epoch of 1970-01-01T00:00:00Z where instants after the epoch have positive values, and earlier instants have negative values. For both the epoch-second and nanosecond parts, a larger value is always later on the time-line than a smaller value.
Modern timekeeping is based on atomic clocks which precisely define an SI second relative to the transitions of a Caesium atom. The length of an SI second was defined to be very close to the 86400th fraction of a day.
Unfortunately, as the Earth rotates the length of the day varies. In addition, over time the average length of the day is getting longer as the Earth slows. As a result, the length of a solar day in 2012 is slightly longer than 86400 SI seconds. The actual length of any given day and the amount by which the Earth is slowing are not predictable and can only be determined by measurement. The UT1 time-scale captures the accurate length of day, but is only available some time after the day has completed.
The UTC time-scale is a standard approach to bundle up all the additional fractions of a second from UT1 into whole seconds, known as leap-seconds. A leap-second may be added or removed depending on the Earth's rotational changes. As such, UTC permits a day to have 86399 SI seconds or 86401 SI seconds where necessary in order to keep the day aligned with the Sun.
The modern UTC time-scale was introduced in 1972, introducing the concept of whole leap-seconds. Between 1958 and 1972, the definition of UTC was complex, with minor sub-second leaps and alterations to the length of the notional second. As of 2012, discussions are underway to change the definition of UTC again, with the potential to remove leap seconds or introduce other changes.
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.
For the segment from 1972-11-03 (exact boundary discussed below) until further notice, the consensus international time scale is UTC (with leap seconds). In this segment, the Java Time-Scale is identical to UTC-SLS. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread equally over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day.
Implementations of the Java time-scale using the JSR-310 API are not required to provide any clock that is sub-second accurate, or that progresses monotonically or smoothly. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds. JSR-310 does, however, require that implementations must document the approach they use when defining a clock representing the current instant. See Clock for details on the available clocks.
This is a value-based class; use of identity-sensitive operations (including reference equality (==), identity hash code, or synchronization) on instances of Instant may have unpredictable results and should be avoided. The equals method should be used for comparisons.
This is one year earlier than the minimum LocalDateTime. This provides sufficient values to handle the range of ZoneOffset which affect the instant in addition to the local date-time. The value is also chosen such that the value of the year fits in an int.
This is one year later than the maximum LocalDateTime. This provides sufficient values to handle the range of ZoneOffset which affect the instant in addition to the local date-time. The value is also chosen such that the value of the year fits in an int.
If the field is not a ChronoField, then the result of this method is obtained by invoking TemporalField.isSupportedBy(TemporalAccessor) passing this as the argument. Whether the field is supported is determined by the field.
If the unit is not a ChronoUnit, then the result of this method is obtained by invoking TemporalUnit.isSupportedBy(Temporal) passing this as the argument. Whether the unit is supported is determined by the unit.
The range object expresses the minimum and maximum valid values for a field. This instant is used to enhance the accuracy of the returned range. If it is not possible to return the range, because the field is not supported or for some other reason, an exception is thrown.
If the field is a ChronoField then the query is implemented here. The supported fields will return appropriate range instances. All other ChronoField instances will throw an UnsupportedTemporalTypeException.
If the field is not a ChronoField, then the result of this method is obtained by invoking TemporalField.rangeRefinedBy(TemporalAccessor) passing this as the argument. Whether the range can be obtained is determined by the field.
This queries this instant for the value of the specified field. The returned value will always be within the valid range of values for the field. If it is not possible to return the value, because the field is not supported or for some other reason, an exception is thrown.
If the field is a ChronoField then the query is implemented here. The supported fields will return valid values based on this date-time, except INSTANT_SECONDS which is too large to fit in an int and throws a DateTimeException. All other ChronoField instances will throw an UnsupportedTemporalTypeException.
If the field is not a ChronoField, then the result of this method is obtained by invoking TemporalField.getFrom(TemporalAccessor) passing this as the argument. Whether the value can be obtained, and what the value represents, is determined by the field.
If the field is a ChronoField then the query is implemented here. The supported fields will return valid values based on this date-time. All other ChronoField instances will throw an UnsupportedTemporalTypeException.
This returns an Instant, based on this one, with the instant adjusted. The adjustment takes place using the specified adjuster strategy object. Read the documentation of the adjuster to understand what adjustment will be made.
This returns an Instant, based on this one, with the value for the specified field changed. If it is not possible to set the value, because the field is not supported or for some other reason, an exception is thrown.
If the field is a ChronoField then the adjustment is implemented here. The supported fields behave as follows:
- NANO_OF_SECOND - Returns an Instant with the specified nano-of-second. The epoch-second will be unchanged.
- MICRO_OF_SECOND - Returns an Instant with the nano-of-second replaced by the specified micro-of-second multiplied by 1,000. The epoch-second will be unchanged.
- MILLI_OF_SECOND - Returns an Instant with the nano-of-second replaced by the specified milli-of-second multiplied by 1,000,000. The epoch-second will be unchanged.
- INSTANT_SECONDS - Returns an Instant with the specified epoch-second. The nano-of-second will be unchanged.
If the field is not a ChronoField, then the result of this method is obtained by invoking TemporalField.adjustInto(Temporal, long) passing this as the argument. In this case, the field determines whether and how to adjust the instant.
Truncating the instant returns a copy of the original with fields smaller than the specified unit set to zero. The fields are calculated on the basis of using a UTC offset as seen in toString. For example, truncating with the MINUTES unit will round down to the nearest minute, setting the seconds and nanoseconds to zero.
The calculation is delegated to the amount object by calling TemporalAmount.addTo(Temporal). The amount implementation is free to implement the addition in any way it wishes, however it typically calls back to plus(long, TemporalUnit). Consult the documentation of the amount implementation to determine if it can be successfully added.
This returns an Instant, based on this one, with the amount in terms of the unit added. If it is not possible to add the amount, because the unit is not supported or for some other reason, an exception is thrown.
If the field is a ChronoUnit then the addition is implemented here. The supported fields behave as follows:
- NANOS - Returns an Instant with the specified number of nanoseconds added. This is equivalent to plusNanos(long).
- MICROS - Returns an Instant with the specified number of microseconds added. This is equivalent to plusNanos(long) with the amount multiplied by 1,000.
- MILLIS - Returns an Instant with the specified number of milliseconds added. This is equivalent to plusNanos(long) with the amount multiplied by 1,000,000.
- SECONDS - Returns an Instant with the specified number of seconds added. This is equivalent to plusSeconds(long).
- MINUTES - Returns an Instant with the specified number of minutes added. This is equivalent to plusSeconds(long) with the amount multiplied by 60.
- HOURS - Returns an Instant with the specified number of hours added. This is equivalent to plusSeconds(long) with the amount multiplied by 3,600.
- HALF_DAYS - Returns an Instant with the specified number of half-days added. This is equivalent to plusSeconds(long) with the amount multiplied by 43,200 (12 hours).
- DAYS - Returns an Instant with the specified number of days added. This is equivalent to plusSeconds(long) with the amount multiplied by 86,400 (24 hours).