Date parsing/formatting with TimeZone and SimpleDateFormat give different results around DST switch

I went throe multiple posts about TimeZone and SimpleDateFormat on Google and Stack Overflow, but still do not get what I'm doing wrong. I'm working on some legacy code, and there is a method parseDate, which gives wrong results.

I attached sample JUnit which I'm trying to use do investigate issue.

First method (testParseStrangeDate_IBM_IBM) uses IBM's implementation to format output of parseDate method. Second formats output with Sun's implementation.

Using Sun's SimpleDateFormat gives us time different by an hour (which might be related to Day Light Savings). Setting default TimeZone to IBM's implementation fixes parseDate method (simply uncomment 3 lines in setupDefaultTZ method).

I am sure it's not a bug, but I am doing something wrong.

@Test
public void testParseStrangeDate_IBM_IBM() {
    setupDefaultTZ();

    Calendar date = parseDate("2010-03-14T02:25:00");
    com.ibm.icu.text.SimpleDateFormat dateFormat = new com.ibm.icu.text.SimpleDateFormat(
            "yyyy-MM-dd HH:mm:ss");

    // PASSES:
    assertEquals("2010-03-14 02:25:00", dateFormat.format(date.getTime()));
}

@Test
public void testParseStrangeDate_SUN_SUN() {
    setupDefaultTZ();

    Calendar date = parseDate("2010-03-14T02:25:00");
    java.text.SimpleDateFormat dateFormat = new java.text.SimpleDateFormat(
            "yyyy-MM-dd HH:mm:ss");

    // FAILS:
    assertEquals("2010-03-14 02:25:00", dateFormat.format(date.getTime()));
}

public static Calendar parseDate(String varDate) {
    Calendar cal = null;
    try {
        // DOES NOT MAKE ANY DIFFERENCE:
        // com.ibm.icu.text.SimpleDateFormat simpleDateFormat = new
        // com.ibm.icu.text.SimpleDateFormat(
        // "yyyy-MM-dd'T'HH:mm:ss");
        java.text.SimpleDateFormat simpleDateFormat = new java.text.SimpleDateFormat(
                "yyyy-MM-dd'T'HH:mm:ss", Locale.US);
        Date date = simpleDateFormat.parse(varDate);
        cal = GregorianCalendar.getInstance();
        cal.setTimeInMillis(date.getTime());
        System.out.println("CAL: [" + cal + "]");
    } catch (ParseException pe) {
        pe.printStackTrace();
    }
    return cal;
}

private void setupDefaultTZ() {
    java.util.TimeZone timeZoneSun = java.util.TimeZone.getTimeZone("America/Chicago");
    java.util.TimeZone.setDefault(timeZoneSun);

    // UNCOMMENTING THIS ONE FIXES SUN PARSING ??
    // com.ibm.icu.util.TimeZone timeZoneIbm = com.ibm.icu.util.TimeZone
  开发者_C百科  // .getTimeZone("America/Chicago");
    // com.ibm.icu.util.TimeZone.setDefault(timeZoneIbm);

    Locale.setDefault(Locale.US);
}

---

The trouble is, you've specified a time which doesn't exist. The clocks go forward such that 2am becomes 3am - 2:25am never happens.

Now, there are various options for what could happen here. In Noda Time I believe we'd throw an exception (that's the plan anyway); I believe Joda Time (a far better Java API than Date/Calendar/SimpleDateFormat - you should consider migrating to it if you possibly can) will give you 3:25am, i.e. 25 minutes after the transition.

What would you want to happen when you're given a date/time combination which is impossible due to the DST transition? In this situation it's hard to know for sure what you mean by the "wrong" results. I would say your unit test is somewhat flawed - there is no possible time which should be formatted to that time.

My guess as to why the IBM time zone "works" is that it may use old time zone data, from before the US changed its DST transitions. Try using March 28th, which is when I think it would have been otherwise - you'll probably find the tests fail in the same way with the IBM zone, but not with the Sun one :) (As the Sun zone won't consider it a DST transition.)