-
Bug
-
Resolution: Fixed
-
P3
-
1.2.1
-
007
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2027014 | 1.3.0 | Masayoshi Okutsu | P3 | Resolved | Fixed | beta |
JDK-2027013 | 1.2.2_004 | Masayoshi Okutsu | P3 | Resolved | Fixed | b04 |
JDK-2027012 | 1.2.2_001 | Masayoshi Okutsu | P3 | Resolved | Fixed | b01 |
JDK-2027011 | 1.2.1_003 | Masayoshi Okutsu | P3 | Resolved | Fixed | b03 |
JDK-2027010 | 1.1.7 | Masayoshi Okutsu | P3 | Resolved | Fixed | 005 |
See java.util.Date.parse()
Spec does not say how 2-digit years are interpreted. A sliding window is now
used - year is assumed to be within the range (current - 80 years to now + 19
years) I think. Looks like this was changed for 1.1.6 (and 1.2) but never
documented.
There is a comment at the top of the class which says that a year y is always
represented in this class by y-1900. This is now misleading.
Also, there are typos "ATtempts" and "teh" in the first three lines of the
docs for this method. Just because it is deprecated doesn't mean we should
be sloppy!
- backported by
-
JDK-2027010 Spec/docs inconsistent with impl on Date.parse with 2-digit year
-
- Resolved
-
-
JDK-2027011 Spec/docs inconsistent with impl on Date.parse with 2-digit year
-
- Resolved
-
-
JDK-2027012 Spec/docs inconsistent with impl on Date.parse with 2-digit year
-
- Resolved
-
-
JDK-2027013 Spec/docs inconsistent with impl on Date.parse with 2-digit year
-
- Resolved
-
-
JDK-2027014 Spec/docs inconsistent with impl on Date.parse with 2-digit year
-
- Resolved
-