Bug 11085 - SimpleDateFormat fails to parse valid dates
Summary: SimpleDateFormat fails to parse valid dates
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-04 05:24 UTC by Charles Duffy
Modified: 2005-03-23 21:38 UTC (History)
3 users (show)

See Also:
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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Duffy 2003-06-04 05:24:49 UTC
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.
Comment 1 Andrew Pinski 2003-06-05 15:09:33 UTC
Confirmed with 3.3.1 (20030526) and the mainline (20030604).
Comment 2 Tom Tromey 2003-06-08 02:04:37 UTC
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.
Comment 3 Dara Hazeghi 2003-06-20 01:40:12 UTC
Tom,

did the patch you checked in at http://gcc.gnu.org/ml/gcc-cvs/2003-06/msg00347.html fix this 
problem? Thanks,

Dara
Comment 4 Andrew Pinski 2003-07-24 15:44:19 UTC
It still fails on the mainline (20030724).
Comment 5 Andrew John Hughes 2005-01-22 03:29:50 UTC
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.
Comment 6 CVS Commits 2005-03-23 21:26:13 UTC
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

Comment 7 CVS Commits 2005-03-23 21:36:40 UTC
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

Comment 8 Tom Tromey 2005-03-23 21:38:40 UTC
Fix checked in.