| Bug #96276 | Retrieval of DATETIME with value in DST lost hour causes error | ||
|---|---|---|---|
| Submitted: | 22 Jul 2019 21:34 | Modified: | 13 Feb 2020 15:40 |
| Reporter: | Josh Landin | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | Connector / J | Severity: | S2 (Serious) |
| Version: | 8.0.16, 8.0.17 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[24 Jul 2019 7:31]
MySQL Verification Team
Hello Josh Landin, Thank you for the report. regards, Umesh
[24 Jul 2019 7:38]
MySQL Verification Team
Workaround which worked for me is to set serverTimezone=UTC. More - https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitatio...
[24 Jul 2019 18:35]
Josh Landin
Using serverTimezone=UTC as a workaround would cause the datetime to come back as "2019-03-09 21:00:00", which is not desirable.
[13 Feb 2020 15:40]
Alexander Soklakov
Hi Josh, This is a duplicate of Bug#93444.
[18 Feb 2020 10:55]
Alexander Soklakov
Actually, it's a duplicate of Bug#82005.
Description: With server/client in New York timezone -- Under Connector/J 5.x, retrieving a DATETIME value such as "2019-03-10 02:00:00" (which is within the DST lost hour) would yield a Timestamp of "2019-03-10 03:00:00". Under Connector/J 8.x, attempts to retrieve this value will fail with: Caused by: java.lang.IllegalArgumentException: HOUR_OF_DAY: 2 -> 3 at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2829) at java.util.Calendar.updateTime(Calendar.java:3393) at java.util.Calendar.getTimeInMillis(Calendar.java:1782) at com.mysql.cj.result.SqlTimestampValueFactory.localCreateFromTimestamp(SqlTimestampValueFactory.java:106) How to repeat: DDL: CREATE TABLE `theTable` ( `theDate` DATETIME DEFAULT NULL ); Java: st.executeUpdate("INSERT INTO theTable (theDate) VALUES ('2019-03-10 02:00:00')"); ResultSet rs = st.executeQuery("SELECT theDate FROM theTable"); rs.next(); Timestamp theDate = rs.getTimestamp("theDate"); // Exception is thrown. Suggested fix: Turning on leniency in the Calendar used by SqlTimestampValueFactory would fix the issue, but I'm not sure if that's a desirable fix. Remove line SqlTimestampValueFactory.java:67 ... cal.setLenient(false);