Examples of ZonedDateTime

java.time.ZonedDateTime
A date-time with a time-zone in the ISO-8601 calendar system, such as {@code 2007-12-03T10:15:30+01:00 Europe/Paris}.
{@code ZonedDateTime} is an immutable representation of a date-time with a time-zone.This class stores all date and time fields, to a precision of nanoseconds, and a time-zone, with a zone offset used to handle ambiguous local date-times. For example, the value "2nd October 2007 at 13:45.30.123456789 +02:00 in the Europe/Paris time-zone" can be stored in a {@code ZonedDateTime}.
This class handles conversion from the local time-line of {@code LocalDateTime}to the instant time-line of {@code Instant}. The difference between the two time-lines is the offset from UTC/Greenwich, represented by a {@code ZoneOffset}.
Converting between the two time-lines involves calculating the offset using the {@link ZoneRules rules} accessed from the {@code ZoneId}. Obtaining the offset for an instant is simple, as there is exactly one valid offset for each instant. By contrast, obtaining the offset for a local date-time is not straightforward. There are three cases:
- Normal, with one valid offset. For the vast majority of the year, the normal case applies, where there is a single valid offset for the local date-time.
- Gap, with zero valid offsets. This is when clocks jump forward typically due to the spring daylight savings change from "winter" to "summer". In a gap there are local date-time values with no valid offset.
- Overlap, with two valid offsets. This is when clocks are set back typically due to the autumn daylight savings change from "summer" to "winter". In an overlap there are local date-time values with two valid offsets.
Any method that converts directly or implicitly from a local date-time to an instant by obtaining the offset has the potential to be complicated.
For Gaps, the general strategy is that if the local date-time falls in the middle of a Gap, then the resulting zoned date-time will have a local date-time shifted forwards by the length of the Gap, resulting in a date-time in the later offset, typically "summer" time.
For Overlaps, the general strategy is that if the local date-time falls in the middle of an Overlap, then the previous offset will be retained. If there is no previous offset, or the previous offset is invalid, then the earlier offset is used, typically "summer" time.. Two additional methods, {@link #withEarlierOffsetAtOverlap()} and {@link #withLaterOffsetAtOverlap()}, help manage the case of an overlap.
In terms of design, this class should be viewed primarily as the combination of a {@code LocalDateTime} and a {@code ZoneId}. The {@code ZoneOffset} isa vital, but secondary, piece of information, used to ensure that the class represents an instant, especially during a daylight savings overlap.
This is a value-based class; use of identity-sensitive operations (including reference equality ( {@code ==}), identity hash code, or synchronization) on instances of {@code ZonedDateTime} may have unpredictable results and should be avoided.The {@code equals} method should be used for comparisons. @implSpec A {@code ZonedDateTime} holds state equivalent to three separate objects,a {@code LocalDateTime}, a {@code ZoneId} and the resolved {@code ZoneOffset}. The offset and local date-time are used to define an instant when necessary. The zone ID is used to obtain the rules for how and when the offset changes. The offset cannot be freely set, as the zone controls which offsets are valid.
This class is immutable and thread-safe. @since 1.8
org.threeten.bp.ZonedDateTime
A date-time with a time-zone in the ISO-8601 calendar system, such as {@code 2007-12-03T10:15:30+01:00 Europe/Paris}.
{@code ZonedDateTime} is an immutable representation of a date-time with a time-zone.This class stores all date and time fields, to a precision of nanoseconds, and a time-zone, with a zone offset used to handle ambiguous local date-times. For example, the value "2nd October 2007 at 13:45.30.123456789 +02:00 in the Europe/Paris time-zone" can be stored in a {@code ZonedDateTime}.
This class handles conversion from the local time-line of {@code LocalDateTime}to the instant time-line of {@code Instant}. The difference between the two time-lines is the offset from UTC/Greenwich, represented by a {@code ZoneOffset}.
Converting between the two time-lines involves calculating the offset using the {@link ZoneRules rules} accessed from the {@code ZoneId}. Obtaining the offset for an instant is simple, as there is exactly one valid offset for each instant. By contrast, obtaining the offset for a local date-time is not straightforward. There are three cases:
- Normal, with one valid offset. For the vast majority of the year, the normal case applies, where there is a single valid offset for the local date-time.
- Gap, with zero valid offsets. This is when clocks jump forward typically due to the spring daylight savings change from "winter" to "summer". In a gap there are local date-time values with no valid offset.
- Overlap, with two valid offsets. This is when clocks are set back typically due to the autumn daylight savings change from "summer" to "winter". In an overlap there are local date-time values with two valid offsets.
Any method that converts directly or implicitly from a local date-time to an instant by obtaining the offset has the potential to be complicated.
For Gaps, the general strategy is that if the local date-time falls in the middle of a Gap, then the resulting zoned date-time will have a local date-time shifted forwards by the length of the Gap, resulting in a date-time in the later offset, typically "summer" time.
For Overlaps, the general strategy is that if the local date-time falls in the middle of an Overlap, then the previous offset will be retained. If there is no previous offset, or the previous offset is invalid, then the earlier offset is used, typically "summer" time.. Two additional methods, {@link #withEarlierOffsetAtOverlap()} and {@link #withLaterOffsetAtOverlap()}, help manage the case of an overlap.
Specification for implementors
A {@code ZonedDateTime} holds state equivalent to three separate objects,a {@code LocalDateTime}, a {@code ZoneId} and the resolved {@code ZoneOffset}. The offset and local date-time are used to define an instant when necessary. The zone ID is used to obtain the rules for how and when the offset changes. The offset cannot be freely set, as the zone controls which offsets are valid.
This class is immutable and thread-safe.

Examples of org.threeten.bp.ZonedDateTime

   */
  public static InterestRateFutureSecurityDefinition fromFixingPeriodStartDate(final ZonedDateTime fixingPeriodStartDate, final IborIndex iborIndex, final double notional,
      final double paymentAccrualFactor, final String name, final Calendar calendar) {
    ArgumentChecker.notNull(fixingPeriodStartDate, "Fixing period start date");
    ArgumentChecker.notNull(iborIndex, "Ibor index");
    final ZonedDateTime lastTradingDate = ScheduleCalculator.getAdjustedDate(fixingPeriodStartDate, -iborIndex.getSpotLag(), calendar);
    final ZonedDateTime fixingPeriodEndDate = ScheduleCalculator.getAdjustedDate(fixingPeriodStartDate, iborIndex, calendar);
    return new InterestRateFutureSecurityDefinition(lastTradingDate, fixingPeriodStartDate, fixingPeriodEndDate, iborIndex, notional, paymentAccrualFactor, name, calendar);
  }

View Full Code Here

0 1 2 3 4 5

TOP

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.

Examples of ZonedDateTime

Specification for implementors

Examples of org.threeten.bp.ZonedDateTime