JDK-6485772 : (tz) java 5.0_08 unable to parse 1930's DST days,throwing java.text.ParseException: Unparseable date
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0u8
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-10-24
  • Updated: 2010-07-29
  • Resolved: 2006-10-25
Related Reports
Relates :  
JDK-4266783 - java.util.GregorianCalendar: incorrect validation in non-lenient
Description
JAVA 5 update 8(and update 6& 10) failed to parse DST days when -Duser.timezone=America/Montreal is used . These DST days are
in the 1930's:
   4/28/1935, 4/26/1936, 4/25/1937

If -Duser.timezone=America/Montreal is not used the DST days are parsed correctly. The day
immediately before and after the DST day are parsed correctly.

JDK 1.3.1_18 and 1.4.2_12 do not have the problem.

The following timezone do not have the problem:
-Duser.timezone=Africa/Abidjan
-Duser.timezone=AMERICA/ALASKA
-Duser.timezone=AMERICA/LOS_ANGELES

============================================
locale=en
============================================
file.encoding [ISO646-US]
file.encoding.pkg [sun.io]
sun.io.unicode.encoding [UnicodeBig]
sun.jnu.encoding [ISO646-US]
user.language [en]
user.timezone [America/Montreal]
============================================
dateStrings[0] [19350427T00:00:00000]
date [Sat Apr 27 00:00:00 EST 1935]
+++++++++++++++++++++

dateStrings[1] [19350428T00:00:00000]
===== Exception parsing date [19350428T00:00:00000]
java.text.ParseException: Unparseable date: "19350428T00:00:00000"
	at java.text.DateFormat.parse(DateFormat.java:335)
	at TestSimpleDateFormat.dumpDates(TestSimpleDateFormat.java:91)
	at TestSimpleDateFormat.main(TestSimpleDateFormat.java:38)

+++++++++++++++++++++

dateStrings[2] [19350429T00:00:00000]
date [Mon Apr 29 00:00:00 EDT 1935]
+++++++++++++++++++++

dateStrings[3] [19360425T00:00:00000]
date [Sat Apr 25 00:00:00 EST 1936]
+++++++++++++++++++++

dateStrings[4] [19360426T00:00:00000]
===== Exception parsing date [19360426T00:00:00000]
java.text.ParseException: Unparseable date: "19360426T00:00:00000"
	at java.text.DateFormat.parse(DateFormat.java:335)
	at TestSimpleDateFormat.dumpDates(TestSimpleDateFormat.java:91)
	at TestSimpleDateFormat.main(TestSimpleDateFormat.java:38)

+++++++++++++++++++++

dateStrings[5] [19360427T00:00:00000]
date [Mon Apr 27 00:00:00 EDT 1936]
+++++++++++++++++++++

dateStrings[6] [19370424T00:00:00000]
date [Sat Apr 24 00:00:00 EST 1937]
+++++++++++++++++++++

dateStrings[7] [19370425T00:00:00000]
===== Exception parsing date [19370425T00:00:00000]
java.text.ParseException: Unparseable date: "19370425T00:00:00000"
	at java.text.DateFormat.parse(DateFormat.java:335)
	at TestSimpleDateFormat.dumpDates(TestSimpleDateFormat.java:91)
	at TestSimpleDateFormat.main(TestSimpleDateFormat.java:38)

+++++++++++++++++++++

dateStrings[8] [19370426T00:00:00000]
date [Mon Apr 26 00:00:00 EDT 1937]
+++++++++++++++++++++

dateStrings[9] [19610429T00:00:00000]
date [Sat Apr 29 00:00:00 EST 1961]
+++++++++++++++++++++

dateStrings[10] [19610430T00:00:00000]
date [Sun Apr 30 00:00:00 EST 1961]
+++++++++++++++++++++

dateStrings[11] [19610501T00:00:00000]
date [Mon May 01 00:00:00 EDT 1961]
+++++++++++++++++++++

dateStrings[12] [20040401T00:00:00000]
date [Thu Apr 01 00:00:00 EST 2004]
+++++++++++++++++++++

dateStrings[13] [20060402T00:00:00000]
date [Sun Apr 02 00:00:00 EST 2006]
+++++++++++++++++++++

dateStrings[14] [20060403T00:00:00000]
date [Mon Apr 03 00:00:00 EDT 2006]
+++++++++++++++++++++

============================================
Comments
WORK AROUND Although I'm not familiar with the particular application, I'd suggest that "yyyyMMdd'T'" be used as the pattern for SimpleDateFormat. This way, parse() can still detect wrong dates, such as "20060229T00:00:00000". The time of day value is adjusted to existing local time. For example, if the given string is "19350428T00:00:00000", the parse() call produces Sun Apr 28 01:00:00 EDT 1935.
30-10-2006
EVALUATION The gmt offset transitions in America/Montreal in 1935 to 1937 are as follows. (See Solaris or Linux zdump man page for the format.) America/Montreal Sun Apr 28 04:59:59 1935 UTC = Sat Apr 27 23:59:59 1935 EST isdst=0 America/Montreal Sun Apr 28 05:00:00 1935 UTC = Sun Apr 28 01:00:00 1935 EDT isdst=1 America/Montreal Sun Sep 29 03:59:59 1935 UTC = Sat Sep 28 23:59:59 1935 EDT isdst=1 America/Montreal Sun Sep 29 04:00:00 1935 UTC = Sat Sep 28 23:00:00 1935 EST isdst=0 America/Montreal Sun Apr 26 04:59:59 1936 UTC = Sat Apr 25 23:59:59 1936 EST isdst=0 America/Montreal Sun Apr 26 05:00:00 1936 UTC = Sun Apr 26 01:00:00 1936 EDT isdst=1 America/Montreal Sun Sep 27 03:59:59 1936 UTC = Sat Sep 26 23:59:59 1936 EDT isdst=1 America/Montreal Sun Sep 27 04:00:00 1936 UTC = Sat Sep 26 23:00:00 1936 EST isdst=0 America/Montreal Sun Apr 25 04:59:59 1937 UTC = Sat Apr 24 23:59:59 1937 EST isdst=0 America/Montreal Sun Apr 25 05:00:00 1937 UTC = Sun Apr 25 01:00:00 1937 EDT isdst=1 America/Montreal Sun Sep 26 03:59:59 1937 UTC = Sat Sep 25 23:59:59 1937 EDT isdst=1 America/Montreal Sun Sep 26 04:00:00 1937 UTC = Sat Sep 25 23:00:00 1937 EST isdst=0 So, the specified local times didn't exist and are invalid in America/Montreal. In 1.4.2 and earlier, GregorianCalendar doesn't validate the given local time in non-lenient mode.
25-10-2006