I have get the date from server in iso8601 format
serverTimeDateFormat.parse("2019-04-10T16:04:14.677Z")
when I am parsing the date it give the time corresponding to my location, but it is 1 hour behind (GMT+1 while it is GMT+2) What is the solution for this ? How can I consider that there was switch to summer time but still it calculates based on winter time

- 257
- 3
- 20
-
1As an aside consider throwing away the long outmoded and notoriously troublesome `SimpleDateFormat` and friends, and adding [ThreeTenABP](https://github.com/JakeWharton/ThreeTenABP) to your Android project in order to use `java.time`, the modern Java date and time API. It is so much nicer to work with. – Ole V.V. Apr 11 '19 at 04:41
-
1I’m afraid that the solution is to parse the string correctly! The trailing `Z` is an offset of 0 from UTC. If you pass that as such and either convert to the correct time zone (e.g., Europe/Berlin) (using java.time) or make sure your `SimpleDateFormat` (that I wouldn’t want to use) has the correct time zone set, the rest is automatic. Which time zones have summer time (DST) between which dates is built into Java and requires no special attention from you, the application programmer. – Ole V.V. Apr 11 '19 at 04:45
-
Possible near-duplicate of [Java set timezone does not default to gmt+0](https://stackoverflow.com/questions/47729293/java-set-timezone-does-not-default-to-gmt0). That question doesn’t treat the `Z´ in the original string, though. – Ole V.V. Apr 11 '19 at 04:59
1 Answers
java.time and ThreeTen Backport
ZoneId myTimeZone = ZoneId.of("Europe/Bratislava");
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG)
.withLocale(Locale.forLanguageTag("sk-SK"));
String serverDateTimeString = "2019-04-10T16:04:14.677Z";
Instant dateTime = Instant.parse(serverDateTimeString);
String formattedWithSummerTime = dateTime.atZone(myTimeZone)
.format(formatter);
System.out.println(formattedWithSummerTime);
The output from this snippet is:
- apríla 2019, 18:04:14 SELČ
Even if you don’t speak Slovak, you can recognize that the server time of 16:04:14 has been converted to 18:04:14, that is, GMT+2 as requested. You just substitute your own time zone and your own locale, of course.
Which time zones have summer time (DST) between which dates is built into Java and requires no special attention from you, the application programmer. Many European time zones (and a single African one) are at GMT+1 normally and GMT+2 during summer time, so I just picked one of them for illustration.
I am very consciously avoiding using the SimpleDateFormat
class that you mentioned in your question (though it too knows time zones and summer time and could be used here). That class is notoriously troublesome and fortunately long outdated. Instead I am using java.time, the modern Java date and time API.
What went wrong in your code, then? You haven’t shown it, so I cannot know, but a possible suspicion is that you didn’t parse the server string correctly. Z
means UTC, but programmers sometimes take the it as a literal so the SimpleDateFormat
doesn’t know that the parsed string is in UTC, which leads to an incorrect time.
Question: Can I use java.time on Android?
Yes, java.time works nicely on older and newer Android devices. It just requires at least Java 6.
- In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
- In Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310; see the links at the bottom).
- On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from
org.threeten.bp
with subpackages.
Links
- Oracle tutorial: Date Time explaining how to use java.time.
- Java Specification Request (JSR) 310, where
java.time
was first described. - ThreeTen Backport project, the backport of
java.time
to Java 6 and 7 (ThreeTen for JSR-310). - ThreeTenABP, Android edition of ThreeTen Backport
- Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

- 81,772
- 15
- 137
- 161