- Java utc offset timezone
- Class ZoneOffset
- Field Summary
- Fields inherited from class java.time.ZoneId
- Method Summary
- Time Zone and Offset Classes
- ZoneId and ZoneOffset
- The Date-Time Classes
- ZonedDateTime
- OffsetDateTime
- OffsetTime
- Java utc offset timezone
- Three-letter time zone IDs
- Field Summary
- Class TimeZone
- Three-letter time zone IDs
Java utc offset timezone
Class ZoneOffset
public final class ZoneOffset extends ZoneId implements TemporalAccessor, TemporalAdjuster, ComparableZoneOffset>, Serializable
A time-zone offset from Greenwich/UTC, such as +02:00 . A time-zone offset is the amount of time that a time-zone differs from Greenwich/UTC. This is usually a fixed number of hours and minutes. Different parts of the world have different time-zone offsets. The rules for how offsets vary by place and time of year are captured in the ZoneId class. For example, Paris is one hour ahead of Greenwich/UTC in winter and two hours ahead in summer. The ZoneId instance for Paris will reference two ZoneOffset instances — a +01:00 instance for winter, and a +02:00 instance for summer. In 2008, time-zone offsets around the world extended from -12:00 to +14:00. To prevent any problems with that range being extended, yet still provide validation, the range of offsets is restricted to -18:00 to 18:00 inclusive. This class is designed for use with the ISO calendar system. The fields of hours, minutes and seconds make assumptions that are valid for the standard ISO definitions of those fields. This class may be used with other calendar systems providing the definition of the time fields matches those of the ISO calendar system. Instances of ZoneOffset must be compared using equals(java.lang.Object) . Implementations may choose to cache certain common offsets, however applications must not rely on such caching. This is a value-based class; use of identity-sensitive operations (including reference equality ( == ), identity hash code, or synchronization) on instances of ZoneOffset may have unpredictable results and should be avoided. The equals method should be used for comparisons.
Field Summary
Fields inherited from class java.time.ZoneId
Method Summary
Time Zone and Offset Classes
A time zone is a region of the earth where the same standard time is used. Each time zone is described by an identifier and usually has the format region/city (Asia/Tokyo) and an offset from Greenwich/UTC time. For example, the offset for Tokyo is +09:00.
ZoneId and ZoneOffset
The Date-Time API provides two classes for specifying a time zone or an offset:
- ZoneId specifies a time zone identifier and provides rules for converting between an Instant and a LocalDateTime.
- ZoneOffset specifies a time zone offset from Greenwich/UTC time.
Offsets from Greenwich/UTC time are usually defined in whole hours, but there are exceptions. The following code, from the TimeZoneId example, prints a list of all time zones that use offsets from Greenwich/UTC that are not defined in whole hours.
Set allZones = ZoneId.getAvailableZoneIds(); LocalDateTime dt = LocalDateTime.now(); // Create a List using the set of zones and sort it. List zoneList = new ArrayList(allZones); Collections.sort(zoneList); . for (String s : zoneList) < ZoneId zone = ZoneId.of(s); ZonedDateTime zdt = dt.atZone(zone); ZoneOffset offset = zdt.getOffset(); int secondsOfHour = offset.getTotalSeconds() % (60 * 60); String out = String.format("%35s %10s%n", zone, offset); // Write only time zones that do not have a whole hour offset // to standard out. if (secondsOfHour != 0) < System.out.printf(out); >. >
This example prints the following list to standard out:
America/Caracas -04:30 America/St_Johns -02:30 Asia/Calcutta +05:30 Asia/Colombo +05:30 Asia/Kabul +04:30 Asia/Kathmandu +05:45 Asia/Katmandu +05:45 Asia/Kolkata +05:30 Asia/Rangoon +06:30 Asia/Tehran +04:30 Australia/Adelaide +09:30 Australia/Broken_Hill +09:30 Australia/Darwin +09:30 Australia/Eucla +08:45 Australia/LHI +10:30 Australia/Lord_Howe +10:30 Australia/North +09:30 Australia/South +09:30 Australia/Yancowinna +09:30 Canada/Newfoundland -02:30 Indian/Cocos +06:30 Iran +04:30 NZ-CHAT +12:45 Pacific/Chatham +12:45 Pacific/Marquesas -09:30 Pacific/Norfolk +11:30
The TimeZoneId example also prints a list of all time zone IDs to a file called timeZones .
The Date-Time Classes
The Date-Time API provides three temporal-based classes that work with time zones:
- ZonedDateTime handles a date and time with a corresponding time zone with a time zone offset from Greenwich/UTC.
- OffsetDateTime handles a date and time with a corresponding time zone offset from Greenwich/UTC, without a time zone ID.
- OffsetTime handles time with a corresponding time zone offset from Greenwich/UTC, without a time zone ID.
When would you use OffsetDateTime instead of ZonedDateTime? If you are writing complex software that models its own rules for date and time calculations based on geographic locations, or if you are storing time-stamps in a database that track only absolute offsets from Greenwich/UTC time, then you might want to use OffsetDateTime. Also, XML and other network formats define date-time transfer as OffsetDateTime or OffsetTime.
Although all three classes maintain an offset from Greenwich/UTC time, only ZonedDateTime uses the ZoneRules, part of the java.time.zone package, to determine how an offset varies for a particular time zone. For example, most time zones experience a gap (typically of 1 hour) when moving the clock forward to daylight saving time, and a time overlap when moving the clock back to standard time and the last hour before the transition is repeated. The ZonedDateTime class accommodates this scenario, whereas the OffsetDateTime and OffsetTime classes, which do not have access to the ZoneRules, do not.
ZonedDateTime
The ZonedDateTime class, in effect, combines the LocalDateTime class with the ZoneId class. It is used to represent a full date (year, month, day) and time (hour, minute, second, nanosecond) with a time zone (region/city, such as Europe/Paris).
The following code, from the Flight example, defines the departure time for a flight from San Francisco to Tokyo as a ZonedDateTime in the America/Los Angeles time zone. The withZoneSameInstant and plusMinutes methods are used to create an instance of ZonedDateTime that represents the projected arrival time in Tokyo, after the 650 minute flight. The ZoneRules.isDaylightSavings method determines whether it is daylight saving time when the flight arrives in Tokyo.
A DateTimeFormatter object is used to format the ZonedDateTime instances for printing:
DateTimeFormatter format = DateTimeFormatter.ofPattern("MMM d yyyy hh:mm a"); // Leaving from San Francisco on July 20, 2013, at 7:30 p.m. LocalDateTime leaving = LocalDateTime.of(2013, Month.JULY, 20, 19, 30); ZoneId leavingZone = ZoneId.of("America/Los_Angeles"); ZonedDateTime departure = ZonedDateTime.of(leaving, leavingZone); try < String out1 = departure.format(format); System.out.printf("LEAVING: %s (%s)%n", out1, leavingZone); >catch (DateTimeException exc) < System.out.printf("%s can't be formatted!%n", departure); throw exc; >// Flight is 10 hours and 50 minutes, or 650 minutes ZoneId arrivingZone = ZoneId.of("Asia/Tokyo"); ZonedDateTime arrival = departure.withZoneSameInstant(arrivingZone) .plusMinutes(650); try < String out2 = arrival.format(format); System.out.printf("ARRIVING: %s (%s)%n", out2, arrivingZone); >catch (DateTimeException exc) < System.out.printf("%s can't be formatted!%n", arrival); throw exc; >if (arrivingZone.getRules().isDaylightSavings(arrival.toInstant())) System.out.printf(" (%s daylight saving time will be in effect.)%n", arrivingZone); else System.out.printf(" (%s standard time will be in effect.)%n", arrivingZone);
This produces the following output:
LEAVING: Jul 20 2013 07:30 PM (America/Los_Angeles) ARRIVING: Jul 21 2013 10:20 PM (Asia/Tokyo) (Asia/Tokyo standard time will be in effect.)
OffsetDateTime
The OffsetDateTime class, in effect, combines the LocalDateTime class with the ZoneOffset class. It is used to represent a full date (year, month, day) and time (hour, minute, second, nanosecond) with an offset from Greenwich/UTC time (+/-hours:minutes, such as +06:00 or -08:00).
The following example uses OffsetDateTime with the TemporalAdjuster.lastDay method to find the last Thursday in July 2013.
// Find the last Thursday in July 2013. LocalDateTime localDate = LocalDateTime.of(2013, Month.JULY, 20, 19, 30); ZoneOffset offset = ZoneOffset.of("-08:00"); OffsetDateTime offsetDate = OffsetDateTime.of(localDate, offset); OffsetDateTime lastThursday = offsetDate.with(TemporalAdjusters.lastInMonth(DayOfWeek.THURSDAY)); System.out.printf("The last Thursday in July 2013 is the %sth.%n", lastThursday.getDayOfMonth());
The output from running this code is:
The last Thursday in July 2013 is the 25th.
OffsetTime
The OffsetTime class, in effect, combines the LocalTime class with the ZoneOffset class. It is used to represent time (hour, minute, second, nanosecond) with an offset from Greenwich/UTC time (+/-hours:minutes, such as +06:00 or -08:00).
The OffsetTime class is used in the same situations as the OffsetDateTime class, but when tracking the date is not needed.
Java utc offset timezone
TimeZone represents a time zone offset, and also figures out daylight savings. Typically, you get a TimeZone using getDefault which creates a TimeZone based on the time zone where the program is running. For example, for a program running in Japan, getDefault creates a TimeZone object based on Japanese Standard Time. You can also get a TimeZone using getTimeZone along with a time zone ID. For instance, the time zone ID for the U.S. Pacific Time zone is «America/Los_Angeles». So, you can get a U.S. Pacific Time TimeZone object with:
TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");
You can use the getAvailableIDs method to iterate through all the supported time zone IDs. You can then choose a supported ID to get a TimeZone . If the time zone you want is not represented by one of the supported IDs, then a custom time zone ID can be specified to produce a TimeZone. The syntax of a custom time zone ID is:
CustomID:GMT
Sign Hours:
MinutesGMT
Sign Hours MinutesGMT
Sign Hours Sign: one of+ -
Hours: Digit Digit Digit Minutes: Digit Digit Digit: one of0 1 2 3 4 5 6 7 8 9
Hours must be between 0 to 23 and Minutes must be between 00 to 59. For example, «GMT+10» and «GMT+0010» mean ten hours and ten minutes ahead of GMT, respectively. The format is locale independent and digits must be taken from the Basic Latin block of the Unicode standard. No daylight saving time transition schedule can be specified with a custom time zone ID. If the specified string doesn’t match the syntax, «GMT» is used. When creating a TimeZone , the specified custom time zone ID is normalized in the following syntax:
NormalizedCustomID:GMT
Sign TwoDigitHours:
Minutes Sign: one of+ -
TwoDigitHours: Digit Digit Minutes: Digit Digit Digit: one of0 1 2 3 4 5 6 7 8 9
Three-letter time zone IDs
For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as «PST», «CTT», «AST») are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, «CST» could be U.S. «Central Standard Time» and «China Standard Time»), and the Java platform can then only recognize one of them.
Field Summary
Class TimeZone
Typically, you get a TimeZone using getDefault which creates a TimeZone based on the time zone where the program is running. For example, for a program running in Japan, getDefault creates a TimeZone object based on Japanese Standard Time.
You can also get a TimeZone using getTimeZone along with a time zone ID. For instance, the time zone ID for the U.S. Pacific Time zone is «America/Los_Angeles». So, you can get a U.S. Pacific Time TimeZone object with:
TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");
You can use the getAvailableIDs method to iterate through all the supported time zone IDs. You can then choose a supported ID to get a TimeZone . If the time zone you want is not represented by one of the supported IDs, then a custom time zone ID can be specified to produce a TimeZone. The syntax of a custom time zone ID is:
CustomID:GMT
Sign Hours:
Minutes:
SecondsGMT
Sign Hours:
MinutesGMT
Sign Hours MinutesGMT
Sign Hours Sign: one of+ -
Hours: Digit Digit Digit Minutes: Digit Digit Seconds: Digit Digit Digit: one of0 1 2 3 4 5 6 7 8 9
Hours must be between 0 to 23 and Minutes/Seconds must be between 00 to 59. For example, «GMT+10» and «GMT+0010» mean ten hours and ten minutes ahead of GMT, respectively.
The format is locale independent and digits must be taken from the Basic Latin block of the Unicode standard. No daylight saving time transition schedule can be specified with a custom time zone ID. If the specified string doesn’t match the syntax, «GMT» is used.
When creating a TimeZone , the specified custom time zone ID is normalized in the following syntax:
NormalizedCustomID:GMT
Sign TwoDigitHours:
Minutes [ColonSeconds] Sign: one of+ -
TwoDigitHours: Digit Digit Minutes: Digit Digit ColonSeconds::
Digit Digit Digit: one of0 1 2 3 4 5 6 7 8 9
For example, TimeZone.getTimeZone(«GMT-8»).getID() returns «GMT-08:00». ColonSeconds part only appears if the seconds value is non-zero.
Three-letter time zone IDs
For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as «PST», «CTT», «AST») are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, «CST» could be U.S. «Central Standard Time» and «China Standard Time»), and the Java platform can then only recognize one of them.