How to get default ZoneOffset in java8?

Question

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?

Answer 1

tl;dr

OffsetDateTime.now().getOffset()

Offset versus Time Zone

An offset-from-UTC is merely a number of hour, minutes, and seconds — nothing more.

A time zone is a history of offsets for a particular region plus a set of rules to handle anomalies such as Daylight Saving Time (DST) that cause shifts in the offset over specific periods of time.

Time Zone = ( History-of-offsets + Rules-for-anomalies )

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.

---

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.

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

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

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.

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 adds 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 bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.