SimpleDateFormat ignoring DST offset in Android

Question

In Central Europe, the current time zone (as of 3rd October) is:

CEST / UTC+2

But when I create an instance of SimpleDateFormat in Android now ...

dateTimeFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ");

... it returns CET / UTC+1 as the time zone. So it's ignoring the DST offset which must still be there at the moment. Why is this?

Furthermore, when using the (now deprecated) method getTimezoneOffset() of Date instances, it returns inconsistent results:

(new Date()).getTimezoneOffset() correctly returns -120 (2 hours) while dateTimeFormat.parse("2012-10-03T22:00:00.000+0000").getTimezoneOffset() returns -60 (1 hour).

How can this happen? Am I doing something wrong or is this a known bug?

Note: I've heard that there are libraries which offer better time calculations (e.g. Joda Time), and I've heard that quite often now ;) But using some workarounds, you can just as easily use the built-in Java time library.

And, of course, the timezone is correctly set on my machine.

I too found inconsistencies in the Java time classes and now use the Calendar class exclusively for anything date time related. So far, it's worked for me every time and even has extensive logic for dealing with the different switch overs to Gregorian dates in different locales. I always have 3 static instances on hand, one set to UTC, one to the system timezone and a floating one where I can calc whatever I need (for example user is roaming but has left the device on their home timezone). I name them appropriately so I can never get confused :) — Simon, Oct 03 '12 at 19:31
Thank you! I'm using `GregorianCalendar` as well, but for parsing I need to use `SimpleDateFormat`, don't I? Or is there any method for parsing a date string directly to a `Calendar` instance? After having parsed the string to a `Date` instance, I create a `Calendar` instance out of that. — caw, Oct 03 '12 at 19:34
By the way, in this case, it's rather the `SimpleDateFormat` which causes problems than the `Date` class. — caw, Oct 03 '12 at 19:35
Agreed. Thinking my use cases through, in my apps the user never enters a date. They can select a date from a calendar but that's all. To do this, use their system timezone (I don't consider roaming) and convert to UTC with getTimeZone().getOffset(). Everything after this is done in UTC using the epoch until I display which is done according to a user preference (use system/use UTC) when I simply setTimeInMillis on the appropriate calendar and use a date formatter on the calendar. That way, the formatter has not concept of time zone. — Simon, Oct 03 '12 at 19:56
Oh hang on, I get what you're saying, I think. "How can I parse in a string with an arbitary time zone?" I would strip the timezone off the end and use it to set the timezone on a Calendar instance, then set the calendars time from parsing the string without the time zone. — Simon, Oct 03 '12 at 19:57
Yes, this would be a possible workaround. But definitely, it cannot be the final (best) solution! `SimpleDateFormat` exists with its `parse(...)` method to allow for easy date parsing (including timezones), so there must be a way withound workaround ... — caw, Oct 04 '12 at 21:42
"you can just as easily use the built-in Java time library" - no, you can't use it *just as easily*. The benefits of using Joda are *enormous*. That said, obviously the normal classes should work too. Could you give a short but complete example of your code, and the input/output? You've given bits and pieces, but complete sample code would be useful - especially if you could give the results on desktop Java as well as Android. — Jon Skeet, Oct 08 '12 at 06:35
"That way, the formatter has not concept of time zone." - SimpleDateFormat *always* has the concept of a time zone. That's what setTimeZone is about... — Jon Skeet, Oct 08 '12 at 06:40

score 1 · Answer 1 · edited May 23 '17 at 11:56

1

I have just switched to JODA with is great.

It also works good on Android with the comments in this link: Android Java - Joda Date is slow That make it run faster.

edited May 23 '17 at 11:56

Community

1
1

answered Oct 09 '12 at 09:03

urir

1,960
3
23
40

score 1 · Accepted Answer · answered Oct 12 '12 at 08:31

I don't know if I have properly understood your use case, but from what I have understood when I try this code.

public static void main(String[] args) {
        SimpleDateFormat dateTimeFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ");
        String date="2012-10-03T22:00:00.000+0000";
        try {
            System.out.println(dateTimeFormat.getTimeZone().getDisplayName());
            System.out.println("Today : "+new Date().toString()+ ", Timezone Offset :" +
                    +(new Date()).getTimezoneOffset());
            System.out.println("Parsed Date : "+
                    dateTimeFormat.parse(date).toString()
                    + ", Timezone Offset : "
                    +dateTimeFormat.parse(date).getTimezoneOffset());           
        } catch (ParseException e) {            
            e.printStackTrace();
        }
    }

I am getting an consistent Output i.e :

Central European Time
Today : Wed Oct 03 09:44:56 CEST 2012, Timezone Offset : -120
Parsed Date : Wed Oct 03 23:00:00 CEST 2012, Timezone Offset : -120

Thank you! I'm confused now. Getting the same output as you, but I'm sure I got different output before asking the question here. Can't reproduce the wrong output anymore, so question solved. Strange. — caw, Oct 12 '12 at 16:24

SimpleDateFormat ignoring DST offset in Android

2 Answers2

Linked