Java Calendar timezone change not working as expected

Question

I'm using the java Calendar to create some date at midnight (GMT), then change the timezone to my local timezone to make sure the requested time would be 1:00 (GMT +1). The code below works, incl. 2 successful asserts.

TimeZone TIMEZONE_GMT = TimeZone.getTimeZone("GMT");
TimeZone TIMEZONE_LOCAL = TimeZone.getDefault(); // GMT + 1

private Calendar getMidnightGmtCalendarWithLocalTimezone() {
    Calendar calendar = Calendar.getInstance(Locale.GERMAN);
    calendar.set(2017, Calendar.JANUARY, 1, 0, 0, 0);

    calendar.setTimeZone(TIMEZONE_GMT); // Probably not required
    assertEquals(0, calendar.get(Calendar.HOUR_OF_DAY)); // Assert 1

    // Log.i("TAG", "" + calendar.get(Calendar.HOUR_OF_DAY));

    calendar.setTimeZone(TIMEZONE_LOCAL);
    assertEquals(1, calendar.get(Calendar.HOUR_OF_DAY)); // Assert 2
    return calendar;
}

Now I delete the 1st assert, and I'd expect nothing changes. Reality: the 2nd assert fails now! I've tried to understand the implementation of .get(), and apparently it does also compute some time, so it's not just collecting the value. Still I don't get why my 2nd assert is failing.

The 2nd assert succeeds again when I uncomment the Log line (just to be sure the problem arises from the calendar.get(), and not the assert!)

So first question: why does this happen? Second qeustion: how can I make sure I've got a Calendar instance with the Local timezone when I've set the time on midnight for Timezone GMT? (in other words, how can I correctly convert timezones?)

EDIT: I'm using this on Android, so cannot use Java8. Joda time (as suggested below) is a great alternative, and I'll definately look into that. However, as answer for my question I'd like to know HOW this works with Java7 Calendar, because I'm bound to that code for the moment.

I'd recommend abandoning the Calendar and trying the new java.time package if you're on JDK 8. You should be - it's the only JDK that has not passed its support life end. — duffymo, Feb 10 '17 at 14:17
@duffymo I'm being totally agree with you, just wondering, could you provide any authoritative description about *why* usage of `Calendar` class should be abandoned? — Andremoniy, Feb 10 '17 at 14:26
Authoritative? java.util.Calendar is JDK 1.0 vintage. It's been acknowledged since the beginning that it's convoluted and difficult to use. (Written by IBM, if I recall correctly.) JODA was developed to address those failings. It was so successful that Oracle folded it into JDK 8 as the java.time package. Calendar is a failure that's > 20 years old. It's been replaced by something acknowledged to be a huge improvement. I claim authority based on the history. Is that good enough for you? — duffymo, Feb 10 '17 at 14:31
@duffymo To clarify, Joda-Time inspired java.time, and was led by the same man, Stephen Colbourne. But java.time is re-engineered, *not* a drop-in replacement for Joda-Time. So your sentence about "folded into" is an oversimplification. Otherwise your point is correct: The java.time classes are built into Java 8 and later to supplant the troublesome confusing and flawed old date-time classes such as `Calendar` and `Date` that are now [legacy](https://en.m.wikipedia.org/wiki/Legacy_system). First line of doc for java.time pkg: *The main API for dates, times, instants, and durations.* — Basil Bourque, Feb 10 '17 at 17:37
@BasilBourque, thank you for the correction. I appreciate the education. — duffymo, Feb 10 '17 at 18:16

score 6 · Answer 1 · edited May 23 '17 at 12:18

tl;dr

Use java.time, not java.util.Calendar.

Instant.parse( "2017-01-01T00:00:00Z" )          // UTC.
       .atZone( ZoneId.of( "Africa/Algiers" ) )  // Time zone with offset +01:00.

Avoid `Calendar`

The old date-time classes including Calendar are troublesome, poorly designed, confusing, and flawed. Avoid them. No point in trying to understand their overwrought API.

The legacy date-time classes are supplanted by the java.time package of classes built into Java 8 and later.

`Instant`

The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds.

Instant instant = Instant.parse( "2017-01-01T00:00:00Z" );

instant.toString(): 2017-01-01T00:00:00Z

`ZonedDateTime`

You asked to see that in a time zone that is one hour ahead of UTC. So let's try applying time zone Africa/Algiers to get a ZonedDateTime.

ZoneId z = ZoneId.of( "Africa/Algiers" );
ZonedDateTime zdt = instant.atZone( z );

zdt.toString(): 2017-01-01T01:00+01:00[Africa/Algiers]

`OffsetDateTime`

If you want to construct your UTC date-time via arguments rather than parsing a string (as seen above), pass arguments to a factory method of OffsetDateTime. Specify the convenient constant, ZoneOffset.UTC. Months are numbered sanely, 1-12 for January-December, in contrast to Calendar.

OffsetDateTime odt = OffsetDateTime.of( 2017 , 1 , 1 , 0 , 0 , 0 , 0 , ZoneOffset.UTC ) ;

odt.toString(): 2017-01-01T00:00Z

Similar to above, we can adjust into a time zone. Adjustments are made for anomalies such as Daylight Saving Time (DST).

ZoneId z = ZoneId.of( "Africa/Algiers" );
ZonedDateTime zdt = odt.atZoneSameInstant( z );

zdt.toString(): 2017-01-01T01:00+01:00[Africa/Algiers]

See this code run line in IdeOne.com.

`Locale`

Regarding the use of Locale in the Question’s code… Locale is completely orthogonal to time zone, separate and distinct. A Locale object affects only the formatting of a string being generated to represent the date-time value.

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.

Where to obtain the java.time classes?

Java SE 8 and 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 SE 7
- Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
- 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.

score 0 · Answer 2 · edited May 23 '17 at 10:29

So, I have run the following code snippet:

public static void main(String[] args) throws Exception {
    TimeZone TIMEZONE_GMT = TimeZone.getTimeZone("GMT");

    Calendar calendar = new GregorianCalendar(TimeZone.getTimeZone("Europe/Berlin"));
    calendar.set(2017, Calendar.JANUARY, 1, 0, 0, 0);

    System.out.println(calendar.get(Calendar.HOUR_OF_DAY));
    calendar.setTimeZone(TIMEZONE_GMT); // Probably not required
    System.out.println(calendar.get(Calendar.HOUR_OF_DAY));
}

On executing it, I got 0 and 23 in the console which is correct.

I then commented out the first Sysout statement and it printed 0 (I expected it to print 23).

On exploring a bit more, I found this SO answer which correctly explains that calendar object only stores the milliseconds and TimeZone is not taken into account.

So, if I were you, I would not worry too much about asserts, I would make sure I get a Calendar instance with required timezone (or default timezone if default timezone is set to the timezone you need), e.g:

Calendar calendar = new GregorianCalendar(TimeZone.getTimeZone("Europe/Berlin"));
//OR
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Europe/Berlin"));
//OR
Calendar calendar = Calendar.getInstance(); //If default timezone is Europe/Berlin

Java Calendar timezone change not working as expected

2 Answers2

tl;dr

Avoid Calendar

Instant

ZonedDateTime

OffsetDateTime

Locale