| Summary: | SimpleDateFormat fails to parse valid dates | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Charles Duffy <cduffy> |
| Component: | libgcj | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, java-prs, tromey |
| Priority: | P2 | ||
| Version: | 3.3 | ||
| Target Milestone: | 4.0.0 | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | 2003-12-17 06:04:29 | |
Confirmed with 3.3.1 (20030526) and the mainline (20030604). I looked at this today. I've fixed a couple bugs in this area. I'll check in the patch soon. The bigger problem is that our SimpleDateFormat doesn't understand the "Z" format. I'm leaving this part unfixed for now. Tom, did the patch you checked in at http://gcc.gnu.org/ml/gcc-cvs/2003-06/msg00347.html fix this problem? Thanks, Dara It still fails on the mainline (20030724). In current Classpath CVS head, parsing of this string is now successful. The output of the given test case is: $ java TestParse Result: Wed Jun 04 03:09:35 2003 Fail "Fail" is printed because the value doesn't match the given string. But, this string is the time localized to the timezone of where the class is being run. Sun outputs this localized String, while, at present, the Classpath one is always in GMT. It is clear that the above figure is the time 22:09:35 -0500 shifted five hours forward to GMT. Sun's VM (1.5) also fails the second bit, as it produces the localized output "Wed Jun 04 04:09:35 BST 2003" (being run on a machine in the UK). Comparing the numeric millisecond values is more accurate, and this shows equivalent values (1054696175000) for both VMs, and a mental grasp of the date/time shows that the output is correct. The only possible bug remaining here is that the Date.toString() output is incorrect, as it does not use the timezone field. Whether this is truly a bug or not is open to debate, as there appears to be no documentation on this in java.util.Date other than the requirement for a zzz field. Subject: Bug 11085 CVSROOT: /cvs/gcc Module name: gcc Changes by: tromey@gcc.gnu.org 2005-03-23 21:26:00 Modified files: libjava : ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy <sven@physto.se> PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3431&r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcc&r1=1.27&r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcc&r1=1.26&r2=1.27 Subject: Bug 11085 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: tromey@gcc.gnu.org 2005-03-23 21:36:25 Modified files: libjava : ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy <sven@physto.se> PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.22&r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.27&r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.26&r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32&r2=1.32.2.1 Fix checked in. |
The below test case illustrates the issue. --- import java.util.Date; import java.text.*; public class TestParse { static private final String PARSE_STRING = "yyyyMMddHHmmssZ"; static private final String TEST_DATE = "20030603220935-0500"; static private final String CORRECT_DATE = "Tue Jun 03 22:09:35 CDT 2003"; public static void main(String args[]) throws Exception { SimpleDateFormat sdf = new SimpleDateFormat(PARSE_STRING); Date d = sdf.parse(TEST_DATE, new ParsePosition(0)); System.out.println("Result: " + d); if(d != null && d.toString().equals(CORRECT_DATE)) System.out.println("Pass"); else System.out.println("Fail"); } } --- When run with Sun's runtime, the test passes. When run by gij, it fails on account of sdf.parse() returning a null Date. Note that it *does* parse the following correctly: static private final String PARSE_STRING = "yyyy-dd-HH-mm-ss"; static private final String TEST_DATE = "2003-03-22-09-35"; However, the following also fails: static private final String PARSE_STRING = "yyyy-dd-HH-mm-ssZ"; static private final String TEST_DATE = "2003-03-22-09-35-0500"; ...as does the following: static private final String PARSE_STRING = "yyyy-dd-HH-mm-ss-Z"; static private final String TEST_DATE = "2003-03-22-09-35--0500"; All examples described as failing here have been verified to succeed against Sun's Java 2 runtime, version 1.4.1_01.