使用java8我们知道使用ZoneId.default()可以获得系统默认的ZoneId，但是如何获得默认的ZoneOffset呢?

我看到一个 ZoneId 有一些规则"，每个规则都有一个 ZoneOffset，这意味着一个 ZoneId 可能有多个一个 ZoneOffset?

解决方案

tl;dr

OffsetDateTime.now().getOffset()

但您可能应该使用时区，而不仅仅是与 UTC 的偏移量.

ZoneId.systemDefault()

偏移与时区

ZoneId

正如 yanys 在评论中所建议的，您可以询问

With java8 we know use ZoneId.default() can get system default ZoneId, but how to get default ZoneOffset?

I see that a ZoneId has some "rules" and each rule has a ZoneOffset, is that means a ZoneId may have more than one ZoneOffset?

解决方案

tl;dr

OffsetDateTime.now().getOffset()

But you likely should be using a time zone rather than a mere offset-from-UTC.

ZoneId.systemDefault() 

Offset versus Time Zone

An offset-from-UTC is merely a number of hour, minutes, and seconds — nothing more. For example, -08:00 means eight hours behind the UTC, and +05:45 means five hours and forty-five minutes ahead of UTC.

A time zone is a history of past, present, and future changes to the offset used by the people of a particular region. Anomalies such as Daylight Saving Time (DST) causing shifts in the offset over specific periods of time are tracked over time, in the past as they happened, and in the future when politicians have announced planned changes.

So better to use a zone when known.

The offset for any region varies over time. For example, DST in the United States shifts the offset by an hour for about half the year and then restoring that hour back to the offset during the other half of the year. The entire purpose of a time zone is to document those shifts in offset.

So it really makes no sense to ask for an offset without a date-time. In America/Los_Angeles, for example in part of this year the offset is -08:00 but in another part of the year it is -07:00 during DST.

OffsetDateTime

So let's specify a moment as an OffsetDateTime, and then extract the ZoneOffset.

OffsetDateTime odt = OffsetDateTime.now ();
ZoneOffset zoneOffset = odt.getOffset ();

odt.toString(): 2017-01-02T15:19:47.162-08:00

zoneOffset.toString(): -08:00

That now method is actually applying implicitly the JVM’s current default time zone. I suggest you always make that explicit by specifying your desired/expected time zone. Even if you want the current default zone, say so explicitly to make your intentions clear. Eliminate the ambiguity about whether you intended the default or failed to consider time zone as so often happens with programmers. Call ZoneId.systemDefault.

OffsetDateTime odt = OffsetDateTime.now ( ZoneId.systemDefault () );
ZoneOffset zoneOffset = odt.getOffset ();

ZoneId.systemDefault().toString(): America/Los_Angeles

odt: 2017-01-02T15:19:47.162-08:00

zoneOffsetOfOdt: -08:00

A caution about depending on the default zone: This default can be changed at any moment by any code in any thread within the JVM. If important, ask the user for their intended time zone.

You can ask the offset for its amount of time as a total number of seconds.

int offsetSeconds = zoneOffset.getTotalSeconds ();

offsetSeconds: -28800

ZonedDateTime

Another example: Perhaps you want to know what the offset will be on Christmas Day this year in Québec. Specify the time zone America/Montreal, get a ZonedDateTime, ask for its offset as a ZoneOffset object.

ZoneId z = ZoneId.of( "America/Montreal" );
LocalDate ld = LocalDate.of( 2017 , 12 , 25 );
ZonedDateTime zdtXmas = ld.atStartOfDay( z );
ZoneOffset zoneOffsetXmas = zdtXmas.getOffset();

zdtXmas.toString(): 2017-12-25T00:00-05:00[America/Montreal]

zoneOffsetXmas.toString(): -05:00

zoneOffsetXmas.getTotalSeconds(): -18000

ZoneId

As suggested in the comment by yanys, you can interrogate a ZoneId for a particular ZoneOffset by passing a moment as an Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).

This is just another route to the same destination. Just like with OffsetDateTime and ZonedDateTime discussed above, we are specifying (a) a time zone, and (b) a moment.

Instant instant = zdtXmas.toInstant();
ZoneOffset zo = z.getRules().getOffset( instant );

For ZoneId: America/Montreal at instant: 2017-12-25T05:00:00Z the ZoneOffset is: -05:00

See all these examples’ code live at IdeOne.com.

ZoneOffset.systemDefault – Bug or feature?

The ZoneOffset class, a subclass of ZoneId, is documented as inheriting the systemDefault method. However, this does not actually work.

ZoneOffset zoneOffset = ZoneOffset.systemDefault() ;  // Fails to compile.

error: incompatible types: ZoneId cannot be converted to ZoneOffset

Not sure if this failure-to-compile is a bug or a feature. As discussed above, it does not seem to make sense to me to ever ask for default offset with a date-time, so perhaps the ZoneOffset.systemDefault should indeed fail. But the documentation should say so, with an explanation.

I tried to file a bug on the failure of the doc to address this issue, but gave up, unable to determine where and how to file such a bug report.

Solar Time versus Political time

A bit more about offsets and time zones…

Solar Time has been used since pre-history, tracking each day by noting when the sun is directly overhead. Poke a stick in the ground, and watch its shadow. When the shadow is shortest, when the shadow begins to grow rather than shrink, then you know it is now noon. Formalize that with a sundial to track the hours pass.

With solar time, as you travel from town to town moving westward, noon arrives a little bit later. Moving eastward, noon arrives a bit sooner. So every town has its own noon, shared only with towns to the north and south along the same longitude.

Solar time was largely abandoned in the modern era. As trains, telegraphs, and telephones arrived, so did the need to coordinate temporally. So a point was picked for its near solar time of noon, and a large swath of land so many miles to the west and to the east is declared to all share the same 12:00 on the clock, the same number of hours offset ahead or behind the Greenwich Prime Meridian line. So began the tradition of every train stop displaying prominently a clock to let the town know of the standard time for their larger region rather than solar time for their own town. Generally, towns in the western edge of that time zone region will see their train station clock read 12:00 a little before the sun is overhead. Clocks in towns in the eastern edge of the region read 12:00 a little after the sun is overhead.

Politicians around the world showed a penchant for changing the offset(s) of their jurisdiction. The reasons vary, such diplomacy, war & occupation, and the silliness of Daylight Saving Time (DST). The reasons vary, but their changes come with surprising frequency. A time zone is a name given to a region to track its history of such changes. So an offset-from-UTC is merely a number of hours-minutes-seconds ahead or behind the prime meridian. A time zone is much more: a history of the past, present, and future changes to the offsets of a particular region. While two neighboring regions may today share the same offset-from-UTC, in the past or future they may differ depending on the differing whims or logic of their politicians.

This means modern time-tracking defined by politicians has little to do with geography. For example, the huge country of India today has a single time zone (offset-from-UTC of +05:30). So solar noon (sun directly over your head) is hours apart in various places across the vast subcontinent. The politicians of India decided this to help unify their diverse democracy. In other examples around the world, we see regions use their time zone as a symbol for international relations such as being different than their offending neighbor country, or choosing the same zone as a neighbor as relations thaw as seen recently in North Korea changing to match South Korea. So, nowadays, solar time is only one of several considerations in time-tracking.

---

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes. Hibernate 5 & JPA 2.2 support java.time.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
  • Java 9 brought some minor features and fixes.
• Java SE 6 and Java SE 7
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android (26+) bundle implementations of the java.time classes.
  • For earlier Android (<26), a process known as API desugaring brings a subset of the java.time functionality not originally built into Android.
    • If the desugaring does not offer what you need, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above) to Android. See How to use ThreeTenABP….