The following testcase fails in JDK 1.3.1_11 only. It might be a regression.

import java.text.SimpleDateFormat;
import java.util.Date;

SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd");
sdf.setLenient(false);
Date d1 = sdf.parse("2004.04. customer ");
Date d2 = sdf.parse("2004.04.06");
System.out.println("A date value in PST zone:" + d1.toString());
System.out.println("A date value in PDT zone:" + d2.toString());

OR
@ To make the test complete:
@ .
@ SimpleDateFormat sdf2 = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
@ sdf2.setLenient(false);
@ String s1 = sdf2.format(d1);
@ String s2 = sdf2.format(d2);
@ System.out.println("Canonical version of d1:" + s1);
@ System.out.println("Canonical version of d2:" + s2);
@ .
@ Above test case will return "2004/04/ customer  00:00:00" for d1, and
@ "2004/04/06 01:00:00" for d2.
@ Ideally, both conversions should return 00:00:00 as the time component.
(Incident Review ID: 249946) 
======================================================================
  xxxxx@xxxxx   10/11/04 18:36 GMT

using JDK 1.3.1_09 or JDK 1.4; not using 1.3.1_11
======================================================================


The test program works correctly in lenient mode.
  xxxxx@xxxxx   2004-04-14

There was an oversight in the 4953991 fix. In non-lenient mode, GregorianCalendar.computeTime() doesn't call timeToFields(). Then, 0 is used as its ERA value for calling TimeZone.getOffset(). The 'era' value must be set to the ERA field before the getOffset call in non-lenient.
  xxxxx@xxxxx   2004-04-14

Why is this bug marked as closed and fixed? I still find the issue in 1.3.1_12 and 1.3.1_13. Please provide an update, thank you!