MySQL Bugs: #68063: datetime timezone behavior changes when emulateUnsupportedPstmts falls back to c

Bug #68063	datetime timezone behavior changes when emulateUnsupportedPstmts falls back to c
Submitted:	10 Jan 2013 2:37	Modified:	25 Apr 2013 8:37
Reporter:	Anders Wallgren	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	Connector / J	Severity:	S2 (Serious)
Version:	5.1.22	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
When mysql server returns 1461 (because max_prepared_stmt_count has been exceeded) and emulateUnsupportedPstmts is true, the JDBC driver falls back on a client-side prepared statement.

The problem we are encountering is that the treatment of datetime timezone shifting differs between these two code paths.

When server-side statements are used, datetime values are converted from local to GMT.
When client-side statements are used, datetime values are not converted.

I've played around with the myriad different connection flags but have been unable to come up with combination that behaves the same whether client-side or server-side statements are used.

We finally ended up patching ConnectionImpl.java to temporarily set useLegacyDatetimeCode during the client-side fallback.

How to repeat:

* To increase the likelihood of generating error 1461, set max_prepared_stmt_count to 1
* Use useCursorFetch=true&useServerPrepStmts=true&useJDBCCompliantTimezoneShift=true in the JDBC url
* Call PreparedStatement.setTimestamp using a GMT calendar

Run several different inserts with datetime values.

Verify that the timestamps in the database vary depending on whether a server-side or client-side statement was used.

Tweaked version of ConnectionImpl.java from 5.1.22 that implements the 'hack' described in the bug report.

Attachment: ConnectionImpl.java (application/octet-stream, text), 167.20 KiB.

Hello Anders,

It looks like duplicate of Bug#55398. Could you provide complete repeatable test case here?

This bug is duplicate of Bug#55398, please look there for further progress.