Examples of ZoneId

java.time.ZoneId
A time-zone ID, such as {@code Europe/Paris}.
A {@code ZoneId} is used to identify the rules used to convert betweenan {@link Instant} and a {@link LocalDateTime}. There are two distinct types of ID:
- Fixed offsets - a fully resolved offset from UTC/Greenwich, that uses the same offset for all local date-times
- Geographical regions - an area where a specific set of rules for finding the offset from UTC/Greenwich apply
Most fixed offsets are represented by {@link ZoneOffset}. Calling {@link #normalized()} on any {@code ZoneId} will ensure that afixed offset ID will be represented as a {@code ZoneOffset}.
The actual rules, describing when and how the offset changes, are defined by {@link ZoneRules}. This class is simply an ID used to obtain the underlying rules. This approach is taken because rules are defined by governments and change frequently, whereas the ID is stable.
The distinction has other effects. Serializing the {@code ZoneId} will only sendthe ID, whereas serializing the rules sends the entire data set. Similarly, a comparison of two IDs only examines the ID, whereas a comparison of two rules examines the entire data set.
Time-zone IDs
The ID is unique within the system. There are three types of ID.
The simplest type of ID is that from {@code ZoneOffset}. This consists of 'Z' and IDs starting with '+' or '-'.
The next type of ID are offset-style IDs with some form of prefix, such as 'GMT+2' or 'UTC+01:00'. The recognised prefixes are 'UTC', 'GMT' and 'UT'. The offset is the suffix and will be normalized during creation. These IDs can be normalized to a {@code ZoneOffset} using {@code normalized()}.
The third type of ID are region-based IDs. A region-based ID must be of two or more characters, and not start with 'UTC', 'GMT', 'UT' '+' or '-'. Region-based IDs are defined by configuration, see {@link ZoneRulesProvider}. The configuration focuses on providing the lookup from the ID to the underlying {@code ZoneRules}.
Time-zone rules are defined by governments and change frequently. There are a number of organizations, known here as groups, that monitor time-zone changes and collate them. The default group is the IANA Time Zone Database (TZDB). Other organizations include IATA (the airline industry body) and Microsoft.
Each group defines its own format for the region ID it provides. The TZDB group defines IDs such as 'Europe/London' or 'America/New_York'. TZDB IDs take precedence over other groups.
It is strongly recommended that the group name is included in all IDs supplied by groups other than TZDB to avoid conflicts. For example, IATA airline time-zone region IDs are typically the same as the three letter airport code. However, the airport of Utrecht has the code 'UTC', which is obviously a conflict. The recommended format for region IDs from groups other than TZDB is 'group~region'. Thus if IATA data were defined, Utrecht airport would be 'IATA~UTC'.
Serialization
This class can be serialized and stores the string zone ID in the external form. The {@code ZoneOffset} subclass uses a dedicated format that only stores theoffset from UTC/Greenwich.
A {@code ZoneId} can be deserialized in a Java Runtime where the ID is unknown.For example, if a server-side Java Runtime has been updated with a new zone ID, but the client-side Java Runtime has not been updated. In this case, the {@code ZoneId}object will exist, and can be queried using {@code getId}, {@code equals}, {@code hashCode}, {@code toString}, {@code getDisplayName} and {@code normalized}. However, any call to {@code getRules} will fail with {@code ZoneRulesException}. This approach is designed to allow a {@link ZonedDateTime} to be loaded andqueried, but not modified, on a Java Runtime with incomplete time-zone information.
This is a value-based class; use of identity-sensitive operations (including reference equality ( {@code ==}), identity hash code, or synchronization) on instances of {@code ZoneId} may have unpredictable results and should be avoided.The {@code equals} method should be used for comparisons. @implSpec This abstract class has two implementations, both of which are immutable and thread-safe. One implementation models region-based IDs, the other is {@code ZoneOffset} modellingoffset-based IDs. This difference is visible in serialization. @since 1.8
org.threeten.bp.ZoneId
A time-zone ID, such as {@code Europe/Paris}.
A {@code ZoneId} is used to identify the rules used to convert betweenan {@link Instant} and a {@link LocalDateTime}. There are two distinct types of ID:
- Fixed offsets - a fully resolved offset from UTC/Greenwich, that uses the same offset for all local date-times
- Geographical regions - an area where a specific set of rules for finding the offset from UTC/Greenwich apply
Most fixed offsets are represented by {@link ZoneOffset}. Calling {@link #normalized()} on any {@code ZoneId} will ensure that afixed offset ID will be represented as a {@code ZoneOffset}.
The actual rules, describing when and how the offset changes, are defined by {@link ZoneRules}. This class is simply an ID used to obtain the underlying rules. This approach is taken because rules are defined by governments and change frequently, whereas the ID is stable.
The distinction has other effects. Serializing the {@code ZoneId} will only sendthe ID, whereas serializing the rules sends the entire data set. Similarly, a comparison of two IDs only examines the ID, whereas a comparison of two rules examines the entire data set.
Time-zone IDs
The ID is unique within the system. There are three types of ID.
The simplest type of ID is that from {@code ZoneOffset}. This consists of 'Z' and IDs starting with '+' or '-'.
The next type of ID are offset-style IDs with some form of prefix, such as 'GMT+2' or 'UTC+01:00'. The recognised prefixes are 'UTC', 'GMT' and 'UT'. The offset is the suffix and will be normalized during creation. These IDs can be normalized to a {@code ZoneOffset} using {@code normalized()}.
The third type of ID are region-based IDs. A region-based ID must be of two or more characters, and not start with 'UTC', 'GMT', 'UT' '+' or '-'. Region-based IDs are defined by configuration, see {@link ZoneRulesProvider}. The configuration focuses on providing the lookup from the ID to the underlying {@code ZoneRules}.
Time-zone rules are defined by governments and change frequently. There are a number of organizations, known here as groups, that monitor time-zone changes and collate them. The default group is the IANA Time Zone Database (TZDB). Other organizations include IATA (the airline industry body) and Microsoft.
Each group defines its own format for the region ID it provides. The TZDB group defines IDs such as 'Europe/London' or 'America/New_York'. TZDB IDs take precedence over other groups.
It is strongly recommended that the group name is included in all IDs supplied by groups other than TZDB to avoid conflicts. For example, IATA airline time-zone region IDs are typically the same as the three letter airport code. However, the airport of Utrecht has the code 'UTC', which is obviously a conflict. The recommended format for region IDs from groups other than TZDB is 'group~region'. Thus if IATA data were defined, Utrecht airport would be 'IATA~UTC'.
Serialization
This class can be serialized and stores the string zone ID in the external form. The {@code ZoneOffset} subclass uses a dedicated format that only stores theoffset from UTC/Greenwich.
A {@code ZoneId} can be deserialized in a Java Runtime where the ID is unknown.For example, if a server-side Java Runtime has been updated with a new zone ID, but the client-side Java Runtime has not been updated. In this case, the {@code ZoneId}object will exist, and can be queried using {@code getId}, {@code equals}, {@code hashCode}, {@code toString}, {@code getDisplayName} and {@code normalized}. However, any call to {@code getRules} will fail with {@code ZoneRulesException}. This approach is designed to allow a {@link ZonedDateTime} to be loaded andqueried, but not modified, on a Java Runtime with incomplete time-zone information.
Specification for implementors
This abstract class has two implementations, both of which are immutable and thread-safe. One implementation models region-based IDs, the other is {@code ZoneOffset} modellingoffset-based IDs. This difference is visible in serialization.

Examples of org.threeten.bp.ZoneId

    try {
      time = LocalTime.from(temporal);
    } catch (Exception ex) {
      time = null;
    }
    ZoneId zone = temporal.query(TemporalQueries.zone());
    return new FlexiDateTime(date, time, zone);
  }

View Full Code Here

Examples of org.threeten.bp.ZoneId

      return ImmutableLocalDateDoubleTimeSeries.of(dates, values);
    }
    
    // read old ZonedDateTimeDoubleTimeSeries, see OpenGammaFudgeContext
    if (message.getByOrdinal(0).toString().contains("ZonedDateTimeDoubleTimeSeries")) {
      ZoneId zone = ZoneOffset.UTC;
      try {
        FudgeMsg converter = message.getMessage(1);
        zone = ZoneId.of(converter.getString(1));
      } catch (RuntimeException ex) {
        // ignore
      }
      FudgeMsg fastSeries = message.getMessage(2);
      String encoding = fastSeries.getMessage(1).getString(1);
      long[] instants = (long[]) fastSeries.getValue(2);
      double[] values = (double[]) fastSeries.getValue(3);
      if (encoding.equals("TIME_EPOCH_NANOS")) {  // CSIGNORE
        // correct encoding
      } else if (encoding.equals("TIME_EPOCH_MILLIS")) {
        for (int i = 0; i < instants.length; i++) {
          instants[i] = instants[i] * 1_000_000;
        }
      } else if (encoding.equals("TIME_EPOCH_SECONDS")) {
        for (int i = 0; i < instants.length; i++) {
          instants[i] = instants[i] * 1_000_000_000;
        }
      } else {
        throw new IllegalArgumentException("Unknown time-series encoding");
      }
      return ImmutableZonedDateTimeDoubleTimeSeries.of(instants, values, zone);
    }
    
    // read new format
    int[] dates = (int[]) message.getValue(DATES);
    long[] instants = (long[]) message.getValue(INSTANTS);
    double[] values = (double[]) message.getValue(VALUES);
    String zoneId = message.getString(ZONE);
    if (dates != null) {
      return ImmutableLocalDateDoubleTimeSeries.of(dates, values);
    }
    if (instants != null) {
      if (zoneId != null) {
        ZoneId zone = ZoneId.of(zoneId);
        return ImmutableZonedDateTimeDoubleTimeSeries.of(instants, values, zone);
      } else {
        return ImmutableInstantDoubleTimeSeries.of(instants, values);
      }
    }

View Full Code Here

Examples of org.threeten.bp.ZoneId

    if (regionId == null) {
      throw new OpenGammaRuntimeException("Could not find region for " + security.getIssuerDomicile());
    }
    final Calendar calendar = CalendarUtils.getCalendar(_regionSource, _holidaySource, regionId);
    final Currency currency = security.getCurrency();
    final ZoneId zone = security.getInterestAccrualDate().getZone();
    final ZonedDateTime firstAccrualDate = ZonedDateTime.of(security.getInterestAccrualDate().toLocalDate().atStartOfDay(), zone);
    final ZonedDateTime maturityDate = ZonedDateTime.of(security.getLastTradeDate().getExpiry().toLocalDate().atStartOfDay(), zone);
    final double rate = security.getCouponRate() / 100;
    final DayCount dayCount = security.getDayCount();
    final BusinessDayConvention businessDay = BusinessDayConventionFactory.INSTANCE.getBusinessDayConvention("Following");

View Full Code Here

Examples of org.threeten.bp.ZoneId

    if (!isValidField(fieldData.getString(fieldName))) {
      return null;
    }
    // These will need to be sorted out.
    LocalTime expiryTime = LocalTime.of(17, 00);
    ZoneId zone = ZoneOffset.UTC;
 
    LocalDate localDate = LocalDate.parse(fieldData.getString(fieldName));
    return localDate.atTime(expiryTime).atZone(zone);
  }

View Full Code Here

Examples of org.threeten.bp.ZoneId

      }
      String guaranteeType = fieldData.getString(FIELD_GUARANTOR); // bit unsure about this one.
      String maturityStr = validateAndGetStringField(fieldData, FIELD_MATURITY);
      // These will need to be sorted out.
      LocalTime expiryTime = LocalTime.of(17, 00);
      ZoneId zone = ZoneOffset.UTC;
      Expiry maturity = null;
      try {
        maturity = new Expiry(LocalDate.parse(maturityStr).atTime(expiryTime).atZone(zone), ExpiryAccuracy.DAY_MONTH_YEAR);
      } catch (Exception e) {
        throw new OpenGammaRuntimeException(maturityStr + " returned from bloomberg not in format yyyy-mm-dd", e);

View Full Code Here

Examples of org.threeten.bp.ZoneId

   * Time between dates in different time zones, when one is near midnight.
   * Trouble arises because timeBetween(date1,date2) != -1 * timeBetween(date2,date1).
   * TimeCalculator computes time in ACTACT Daycount convention, hence fractions of a day are rounded to either 0 or 1 day's year fraction..
   */
  public void plat4725() {
    ZoneId gmt = ZoneId.of("GMT");
    ZoneId london = ZoneId.of("+01:00");


    final ZonedDateTime date1 = ZonedDateTime.of(2013, 9, 24, 0, 0, 1, 0, london);
    final ZonedDateTime date2 = ZonedDateTime.of(2013, 9, 24, 9, 2, 45,936, gmt);
    final double time12 = TimeCalculator.getTimeBetween(date1, date2);
    final double time21 = TimeCalculator.getTimeBetween(date2, date1);

View Full Code Here

Examples of org.threeten.bp.ZoneId

  private final LocalDate referenceDate = LocalDate.of(2010, 4, 23);
  private final LocalDate nowDate = LocalDate.of(2013, 3, 5);


  private FunctionExecutionContext mockExecutionContext() {
    final FunctionExecutionContext context = new FunctionExecutionContext();
    final ZoneId zone = ZoneId.of("UTC");
    context.setValuationClock(Clock.fixed(nowDate.atStartOfDay(zone).toInstant(), zone));
    return context;
  }

View Full Code Here

Examples of org.threeten.bp.ZoneId

   * 
   * @param calendar the calendar, not null
   * @return the zoned-date-time, not null
   */
  public static ZonedDateTime toZonedDateTime(GregorianCalendar calendar) {
    ZoneId zone = ZoneId.of(calendar.getTimeZone().getID());
    Instant instant = Instant.ofEpochMilli(calendar.getTimeInMillis());
    return ZonedDateTime.ofInstant(instant, zone);
  }

View Full Code Here

Examples of org.threeten.bp.ZoneId

  public static ZonedDateTime fromFudgeMsg(final FudgeDeserializer deserializer, final FudgeMsg msg) {
    if (msg == null) {
      return null;
    }
    final OffsetDateTime odt = msg.getValue(OffsetDateTime.class, DATETIME_FIELD_NAME);
    final ZoneId zone = msg.getValue(ZoneId.class, ZONE_FIELD_NAME);
    return odt.atZoneSameInstant(zone);
  }

View Full Code Here

Examples of org.threeten.bp.ZoneId


  public static void toFudgeMsg(final FudgeSerializer serializer, final FlexiDateTime object, final MutableFudgeMsg msg) {
    Temporal best = object.toBest();
    best = (best instanceof ZonedDateTime ? ((ZonedDateTime) best).toOffsetDateTime() : best);
    addToMessage(msg, DATETIME_FIELD_NAME, best);
    ZoneId zone = object.getZone();
    if (zone != null && zone instanceof ZoneOffset == false) {
      addToMessage(msg, ZONE_FIELD_NAME, zone);
    }
  }

View Full Code Here

0 1 2 3 4

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 ZoneId

Time-zone IDs

Serialization

Time-zone IDs

Serialization

Specification for implementors

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId

Examples of org.threeten.bp.ZoneId