P3
FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux hex 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
It's not clearly documented, but in general SimpleDateFormat will skip additional whitespace between date elements resp. separators. However, when using a pattern with a two- (or one-) digit year, additional whitespace preceding the year in the input (if given as a 2-digit number) will prevent the correct interpretation of that number as the short form of a 4-digit year and instead take it literally.
For example using a SimpleDateFormat with pattern "MM/dd/yy", the input "01/01/ 2012" (note the space preceding "2012") would be correctly parsed as the first of January in the year 2012, despite the additional spaces. Parsing "01/01/12" (no space) would yield the same result, interpreting "12" as the year 2012. But if an additional space is inserted in front of the "12", the year switches to 12, i.e. parsing "01/01/ 12" (note the space) will surprisingly result in the first of January of the year 12 (and not the expected 2012).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Executing the test case attached to this bug report will demonstrate the problem.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Executing the test case should result in the following output:
Without Space: 01/01/2012
With Space: 01/01/2012
ACTUAL -
This is the actual output when executed with the Oracle JRE 1.7. Note the year "0012" instead of "2012" on the "With Space" line:
Without Space: 01/01/2012
With Space: 01/01/0012
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
public final class TwoDigitYearWithSpaceBug {
public static void main (String[] args) throws ParseException {
final SimpleDateFormat parseFormat = new SimpleDateFormat("MM/dd/yy", Locale.US);
final SimpleDateFormat fmtFormat = new SimpleDateFormat("MM/dd/yyyy", Locale.US);
// Parse input without space:
final Date d1 = parseFormat.parse("01/01/12");
System.out.println("Without Space: " + fmtFormat.format(d1));
// BUG HERE - Parse input with space:
final Date d2 = parseFormat.parse("01/01/ 12");
System.out.println("With Space: " + fmtFormat.format(d2));
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There seems to be no simple workaround for this problem in the general case.
Depending on the use case it might be possible to preprocess input (for example using regexps) to remove additional input. This is usually easy to do for a few specific pattern(s) and locale(s) already known at development/compile time. But a preprocessing solution supporting any SimpleDateFormat with arbitrary patterns and locales will be quite difficult and essentially lead to reimplementing SimpleDateFormat.
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux hex 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
It's not clearly documented, but in general SimpleDateFormat will skip additional whitespace between date elements resp. separators. However, when using a pattern with a two- (or one-) digit year, additional whitespace preceding the year in the input (if given as a 2-digit number) will prevent the correct interpretation of that number as the short form of a 4-digit year and instead take it literally.
For example using a SimpleDateFormat with pattern "MM/dd/yy", the input "01/01/ 2012" (note the space preceding "2012") would be correctly parsed as the first of January in the year 2012, despite the additional spaces. Parsing "01/01/12" (no space) would yield the same result, interpreting "12" as the year 2012. But if an additional space is inserted in front of the "12", the year switches to 12, i.e. parsing "01/01/ 12" (note the space) will surprisingly result in the first of January of the year 12 (and not the expected 2012).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Executing the test case attached to this bug report will demonstrate the problem.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Executing the test case should result in the following output:
Without Space: 01/01/2012
With Space: 01/01/2012
ACTUAL -
This is the actual output when executed with the Oracle JRE 1.7. Note the year "0012" instead of "2012" on the "With Space" line:
Without Space: 01/01/2012
With Space: 01/01/0012
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
public final class TwoDigitYearWithSpaceBug {
public static void main (String[] args) throws ParseException {
final SimpleDateFormat parseFormat = new SimpleDateFormat("MM/dd/yy", Locale.US);
final SimpleDateFormat fmtFormat = new SimpleDateFormat("MM/dd/yyyy", Locale.US);
// Parse input without space:
final Date d1 = parseFormat.parse("01/01/12");
System.out.println("Without Space: " + fmtFormat.format(d1));
// BUG HERE - Parse input with space:
final Date d2 = parseFormat.parse("01/01/ 12");
System.out.println("With Space: " + fmtFormat.format(d2));
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There seems to be no simple workaround for this problem in the general case.
Depending on the use case it might be possible to preprocess input (for example using regexps) to remove additional input. This is usually easy to do for a few specific pattern(s) and locale(s) already known at development/compile time. But a preprocessing solution supporting any SimpleDateFormat with arbitrary patterns and locales will be quite difficult and essentially lead to reimplementing SimpleDateFormat.