← 返回首页
Instant (Java SE 26 & JDK 26)
JavaScript is disabled on your browser.
  1. java.base
  2. java.time
  3. Instant
Contents  
  1. Description
    1. Time-scale
  2. Field Summary
  3. Method Summary
  4. Field Details
    1. EPOCH
    2. MIN
    3. MAX
  5. Method Details
    1. now()
    2. now(Clock)
    3. ofEpochSecond(long)
    4. ofEpochSecond(long, long)
    5. ofEpochMilli(long)
    6. from(TemporalAccessor)
    7. parse(CharSequence)
    8. isSupported(TemporalField)
    9. isSupported(TemporalUnit)
    10. range(TemporalField)
    11. get(TemporalField)
    12. getLong(TemporalField)
    13. getEpochSecond()
    14. getNano()
    15. with(TemporalAdjuster)
    16. with(TemporalField, long)
    17. truncatedTo(TemporalUnit)
    18. plus(TemporalAmount)
    19. plusSaturating(Duration)
    20. plus(long, TemporalUnit)
    21. plusSeconds(long)
    22. plusMillis(long)
    23. plusNanos(long)
    24. minus(TemporalAmount)
    25. minus(long, TemporalUnit)
    26. minusSeconds(long)
    27. minusMillis(long)
    28. minusNanos(long)
    29. query(TemporalQuery)
    30. adjustInto(Temporal)
    31. until(Temporal, TemporalUnit)
    32. until(Instant)
    33. atOffset(ZoneOffset)
    34. atZone(ZoneId)
    35. toEpochMilli()
    36. compareTo(Instant)
    37. isAfter(Instant)
    38. isBefore(Instant)
    39. equals(Object)
    40. hashCode()
    41. toString()
Hide sidebar  Show sidebar

Class Instant

java.lang.Object
java.time.Instant
All Implemented Interfaces: Serializable, Comparable<Instant>, Temporal, TemporalAccessor, TemporalAdjuster
public final class Instant extends Object implements Temporal, TemporalAdjuster, Comparable<Instant>, Serializable
An instantaneous point on the time-line.

This class models a single instantaneous point on the time-line. This might be used to record event time-stamps in the application.

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.

Time-scale

The length of the solar day is the standard way that humans measure time. This has traditionally been subdivided into 24 hours of 60 minutes of 60 seconds, forming an 86,400 second day.

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 86,400th 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 86,400 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 86,399 SI seconds or 86,401 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.

Given the complexity of accurate timekeeping described above, this Java API defines its own time-scale, the Java Time-Scale.

The Java Time-Scale divides each calendar day into exactly 86,400 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.
There are currently, as of 2013, two segments in the Java 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 86,400 seconds per day.

For the segment prior to 1972-11-03, extending back arbitrarily far, the consensus international time scale is defined to be UT1, applied proleptically, which is equivalent to the (mean) solar time on the prime meridian (Greenwich). In this segment, the Java Time-Scale is identical to the consensus international time scale. The exact boundary between the two segments is the instant where UT1 = UTC between 1972-11-03T00:00 and 1972-11-04T12:00.

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.

The Java time-scale is used for all date-time classes. This includes Instant, LocalDate, LocalTime, OffsetDateTime, ZonedDateTime and Duration.

This is a value-based class; programmers should treat instances that are equal as interchangeable and should not use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail. The equals method should be used for comparisons.

Implementation Requirements: This class is immutable and thread-safe. Since: 1.8 See Also:

Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples. Other versions.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2026, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.

Scripting on this page tracks web page traffic, but does not change the content in any way.