-
Bug
-
Resolution: Fixed
-
P4
-
6, 6u10
-
b134
-
x86
-
linux, windows_xp
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2202683 | Naoto Sato | P4 | Closed | Won't Fix |
FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
java.sql.Date.valueOf(s).toString() does not return 's' in some time zones for years larger than 2037. The returned string is one day before 's'. The problem seems to be the begin or end of daylight saving that starts before or at midnight in some time zones.
Probably related is that Calendar throws an IllegalArgumentException with message DAY_OF_MONTH when trying to set this day with hour / minute / second 0 (instead an IllegalArgumentException with the message HOUR_OF_DAY).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See source code.
ACTUAL -
Date.valueOf("2038-03-21")=2038-03-20 America/Havana
Date.valueOf("2038-03-21")=2038-03-20 Cuba
Date.valueOf("2038-10-17")=2038-10-16 America/Asuncion
Date.valueOf("2038-10-10")=2038-10-09 America/Campo_Grande
Date.valueOf("2038-10-10")=2038-10-09 America/Cuiaba
Date.valueOf("2038-10-10")=2038-10-09 America/Santiago
Date.valueOf("2038-10-10")=2038-10-09 Antarctica/Palmer
Date.valueOf("2038-10-10")=2038-10-09 Chile/Continental
Date.valueOf("2038-10-03")=2038-10-02 AGT
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Buenos_Aires
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Catamarca
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/ComodRivadavia
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Cordoba
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Jujuy
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/La_Rioja
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Mendoza
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Rio_Gallegos
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/San_Juan
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Tucuman
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Ushuaia
Date.valueOf("2038-10-03")=2038-10-02 America/Buenos_Aires
Date.valueOf("2038-10-03")=2038-10-02 America/Catamarca
Date.valueOf("2038-10-03")=2038-10-02 America/Cordoba
Date.valueOf("2038-10-03")=2038-10-02 America/Jujuy
Date.valueOf("2038-10-03")=2038-10-02 America/Mendoza
Date.valueOf("2038-10-03")=2038-10-02 America/Rosario
Date.valueOf("2038-10-10")=2038-10-09 America/Sao_Paulo
Date.valueOf("2038-10-10")=2038-10-09 BET
Date.valueOf("2038-10-10")=2038-10-09 Brazil/East
Date.valueOf("2038-03-28")=2038-03-27 America/Scoresbysund
Date.valueOf("2038-03-28")=2038-03-27 Atlantic/Azores
Date.valueOf("2038-03-25")=2038-03-24 Asia/Amman
Date.valueOf("2038-03-28")=2038-03-27 Asia/Beirut
Date.valueOf("2038-04-02")=2038-04-01 Asia/Damascus
Date.valueOf("2038-04-01")=2038-03-31 Asia/Gaza
Date.valueOf("2038-03-21")=2038-03-20 Asia/Tehran
Date.valueOf("2038-03-21")=2038-03-20 Iran
End
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.sql.Date;
import java.util.TimeZone;
public class DateProblem {
public static void main(String[] a) {
String[] ids = TimeZone.getAvailableIDs();
for (int i = 0; i < ids.length; i++) {
TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
for (int y = 2037; y < 2039; y++) {
for (int m = 101; m < 113; m++) {
for (int d = 101; d < 129; d++) {
test(y, m, d);
}
}
}
}
System.out.println("End");
}
static void test(int y, int m, int d) {
String s = y + "-" + ("" + m).substring(1) + "-" + ("" + d).substring(1);
String s2 = Date.valueOf(s).toString();
if (!s.equals(s2)) {
String e = "Date.valueOf(\"" + s + "\")=" + s2;
e += " " + TimeZone.getDefault().getID();
System.out.println(e);
}
}
}
---------- END SOURCE ----------
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
java.sql.Date.valueOf(s).toString() does not return 's' in some time zones for years larger than 2037. The returned string is one day before 's'. The problem seems to be the begin or end of daylight saving that starts before or at midnight in some time zones.
Probably related is that Calendar throws an IllegalArgumentException with message DAY_OF_MONTH when trying to set this day with hour / minute / second 0 (instead an IllegalArgumentException with the message HOUR_OF_DAY).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See source code.
ACTUAL -
Date.valueOf("2038-03-21")=2038-03-20 America/Havana
Date.valueOf("2038-03-21")=2038-03-20 Cuba
Date.valueOf("2038-10-17")=2038-10-16 America/Asuncion
Date.valueOf("2038-10-10")=2038-10-09 America/Campo_Grande
Date.valueOf("2038-10-10")=2038-10-09 America/Cuiaba
Date.valueOf("2038-10-10")=2038-10-09 America/Santiago
Date.valueOf("2038-10-10")=2038-10-09 Antarctica/Palmer
Date.valueOf("2038-10-10")=2038-10-09 Chile/Continental
Date.valueOf("2038-10-03")=2038-10-02 AGT
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Buenos_Aires
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Catamarca
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/ComodRivadavia
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Cordoba
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Jujuy
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/La_Rioja
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Mendoza
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Rio_Gallegos
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/San_Juan
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Tucuman
Date.valueOf("2038-10-03")=2038-10-02 America/Argentina/Ushuaia
Date.valueOf("2038-10-03")=2038-10-02 America/Buenos_Aires
Date.valueOf("2038-10-03")=2038-10-02 America/Catamarca
Date.valueOf("2038-10-03")=2038-10-02 America/Cordoba
Date.valueOf("2038-10-03")=2038-10-02 America/Jujuy
Date.valueOf("2038-10-03")=2038-10-02 America/Mendoza
Date.valueOf("2038-10-03")=2038-10-02 America/Rosario
Date.valueOf("2038-10-10")=2038-10-09 America/Sao_Paulo
Date.valueOf("2038-10-10")=2038-10-09 BET
Date.valueOf("2038-10-10")=2038-10-09 Brazil/East
Date.valueOf("2038-03-28")=2038-03-27 America/Scoresbysund
Date.valueOf("2038-03-28")=2038-03-27 Atlantic/Azores
Date.valueOf("2038-03-25")=2038-03-24 Asia/Amman
Date.valueOf("2038-03-28")=2038-03-27 Asia/Beirut
Date.valueOf("2038-04-02")=2038-04-01 Asia/Damascus
Date.valueOf("2038-04-01")=2038-03-31 Asia/Gaza
Date.valueOf("2038-03-21")=2038-03-20 Asia/Tehran
Date.valueOf("2038-03-21")=2038-03-20 Iran
End
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.sql.Date;
import java.util.TimeZone;
public class DateProblem {
public static void main(String[] a) {
String[] ids = TimeZone.getAvailableIDs();
for (int i = 0; i < ids.length; i++) {
TimeZone.setDefault(TimeZone.getTimeZone(ids[i]));
for (int y = 2037; y < 2039; y++) {
for (int m = 101; m < 113; m++) {
for (int d = 101; d < 129; d++) {
test(y, m, d);
}
}
}
}
System.out.println("End");
}
static void test(int y, int m, int d) {
String s = y + "-" + ("" + m).substring(1) + "-" + ("" + d).substring(1);
String s2 = Date.valueOf(s).toString();
if (!s.equals(s2)) {
String e = "Date.valueOf(\"" + s + "\")=" + s2;
e += " " + TimeZone.getDefault().getID();
System.out.println(e);
}
}
}
---------- END SOURCE ----------
- backported by
-
JDK-2202683 java.sql.Date.valueOf("2042-10-xx").toString() wrong in some time zones
-
- Closed
-
- duplicates
-
JDK-6992200 (cal) BUG in Calendar
-
- Closed
-
- relates to
-
JDK-4845752 (tz) Wrong behavior JDK 1.3.1 in GregorianCalendar at DST boundary time
-
- Resolved
-
-
JDK-8073446 TimeZone getOffset API does not return a DST offset between years 2038-2137
-
- Resolved
-