Java GregorianCalendar change TimeZone

Question

I'm trying to set HOUR_OF_DAY field and change Timezone of the GregorianCalendar date object.

GregorianCalendar date = new GregorianCalendar(TimeZone.getTimeZone("GMT+10"));
System.out.println("HOUR: " + date.get(Calendar.HOUR_OF_DAY));
date.set(Calendar.HOUR_OF_DAY, 23);
//date.get(Calendar.HOUR_OF_DAY);
date.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println("HOUR: " + date.get(Calendar.HOUR_OF_DAY));

Output:

HOUR: 16
HOUR: 23

For some reason value of HOUR_OF_DAY does not change after setting different timezone. But if I uncomment date.get for HOUR_OF_DAY, everything works exactly as it should

GregorianCalendar date = new GregorianCalendar(TimeZone.getTimeZone("GMT+10"));
System.out.println("HOUR: " + date.get(Calendar.HOUR_OF_DAY));
date.set(Calendar.HOUR_OF_DAY, 23);
date.get(Calendar.HOUR_OF_DAY); // uncommenting this line will is changing the output
date.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println("HOUR: " + date.get(Calendar.HOUR_OF_DAY));

Output:

HOUR: 16
HOUR: 13

How is this possible? Why .get method is changing object behaviour?

Answer 1

The GregorianCalendar class inherits its get method from Calendar, which has the following side effect:

In lenient mode, all calendar fields are normalized.

This means that the time value and all fields are recomputed when get is called on a Calendar object. This can lead to some unpredictable behavior, particularly when coupled with setTimeZone, which has some documented buggy behavior of its own.

Answer 2

tl;dr

OffsetDateTime.now( ZoneOffset.ofHours( 10 )  ).withHour( 23 )

Avoid legacy date-time classes

The legacy date-time classes including GregorianCalendar are a confusing. awkward, poorly-design mess. Avoid them. Now supplanted by the java.time classes. Specifically, GregorianCalendar is replaced by ZonedDateTime.

Offset-from-UTC

You apparently want a moment with an offset-from-UTC of ten hours ahead of UTC. Define your desired offset.

ZoneOffset offset = ZoneOffset.ofHours( 10 ) ;

offset.toString(): +10:00

Get the current moment as an OffsetDateTime with that offset.

OffsetDateTime odt = OffsetDateTime.now( offset ) ;

odt.toString(): 2018-02-15T16:44:44.216642+10:00

You want to override the hour to be 23.

OffsetDateTime odt23 = odt.withHour( 23 ) ;

odt23.toString(): 2018-02-15T23:44:44.216642+10:00

Time zone

I'm trying to set HOUR_OF_DAY field and change Timezone of the GregorianCalendar date object.

Nope, you are changing the offset-from-UTC, not the time zone.

Always better to use a time zone rather than a mere offset, if you know for certain the intended zone. A time zone is a history of past, present, and future changes to the offset used by the people of a certain region. With a time zone you can always determine the offset, but not vice-versa.

Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).

ZoneId z = ZoneId.of( "Australia/Brisbane" ) ;  

Capture the current moment in a wall-clock time seen by the people of that zone.

ZonedDateTime zdt = ZonedDateTime.now( z ) ;

Override the hour-of-day.

ZonedDateTime zdt23 = zdt.withHour( 23 ) ;

---

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.

Using a JDBC driver compliant with JDBC 4.2 or later, you may exchange java.time objects directly with your database. No need for strings nor java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, and later
  • Built-in.
  • 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
  • Much 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, 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.