0

I have a problem whereby the Calendar.getTime() method changes the timezone (probably to be in line with the JVM).

Calendar cal  = javax.xml.bind.DatatypeConverter.parseDateTime("2017-10-20T07:10:08.123458Z");
Date datrFromCal = cal.getTime();//Adds two hours(GMT+2:00)

Is there any way to stop this movement from GMT+0 to GMT+2 when calling cal.getTime()?

P.s. We use Java 7 at my company.

Another thing related to this is the support for microseconds. I have read a lot about Java 7 and below not supporting microSeconds (when parsing a String), but is there any suggestions to get around this?

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
Christopher Barrett
  • 147
  • 1
  • 14
  • 1
    Java 7 answer to both your questions: Get [ThreeTen Backport](http://www.threeten.org/threetenbp/) and use the modern Java date and time API. It gives you close control over timezone and offset, and it has straightforward support for microseconds. Plus, it is much nicer to work with in general. – Ole V.V. Jan 18 '18 at 13:58
  • Hi Ole. From the link you sent it indeed looks like I created a duplicate with regards to the timezone part to my question. :( – Christopher Barrett Jan 18 '18 at 14:29
  • 1
    @ChristopherBarrett Your Question is also a duplicate of other topics, including [parsing microseconds](https://stackoverflow.com/questions/22952618/parse-time-with-microseconds-in-java). Search Stack Overflow thoroughly before posting; you can assume most basic date-time questions have already been asked and answered. – Basil Bourque Jan 18 '18 at 20:32

2 Answers2

2

It's not the Date that has the timezone. Dates are simply a number of milliseconds since the "epoch" (1 Jan 1970 GMT). They do not contain timezone information. You only see time zones when you format a date for display. By default, it uses the timezone for your locale. You can use SimpleDateFormat to print a date with a different Locale or TimeZone.

Make sure your Calendar instance has the right TimeZone (e.g. you might have to explicitly set it: cal.setTimeZone(TimeZone.getTimeZone("GMT"));).

If I were you, I'd switch to the Joda time library or the ThreeTen Backport and use the far better designed java.time. The built-in java.util.Date/Calendar classes are a nightmare to work with. They are poorly designed and mutable, which means you can't trust them as value objects to be passed around.

ᴇʟᴇvᴀтᴇ
  • 12,285
  • 4
  • 43
  • 66
  • The answer is correct. I concur, do switch to a more modern date and time API. Now you’re at it, why not pick `java.time`, the modern Java date and time API developed by the folks behind Joda-Time? Joda-Time is in maintenance mode, a finished project, so `java.time` seems the future-proof option. – Ole V.V. Jan 18 '18 at 14:08
  • Thanks Ole. I didn't know there was a backport. I've added it to my answer. – ᴇʟᴇvᴀтᴇ Jan 18 '18 at 14:12
  • Trusting that the parsing is correct, the `Z` in the string should make sure that the `Calendar` has UTC (AKA Zulu) time zone, AKA zero offset. I still agree completely, avoid using that class and move on to `java.time` through the backport. – Ole V.V. Jan 18 '18 at 14:17
0

Though i agree with @ELEVATE, i have to add that the iso 8601 date format uses a time zone.

We can see that you are effectively setting the timezone with the 'Z' indicator but not specify it. Therefore, the calendar is built using the your local time zone but with the time defined as UTC (or GMT if you prefer, therefore as GMT+2h00 in your case).

If, however, you remove the 'Z' indicator, you'll the time set with your timezone as it is.

See https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators for instance

Laurent B
  • 2,200
  • 19
  • 29
  • It depends on the desired time zone. My guess is that the `Z` is there exactly because the OP wants offset 0 from UTC. The OP can best tell. Otherwise you are completely correct. – Ole V.V. Jan 18 '18 at 14:21