Bug #55398 wrong default calendar in setTimestamp in PreparedStatement

• Submitted: 20 Jul 2010 13:13
• Modified: 28 Jun 2021 12:17
• Reporter: Roman Bednarek
• Status: Duplicate
• Category: Connector / J
• Severity: S3 (Non-critical)
• Version: 1.5.6
• OS: Any
• Assigned to: Assigned Account
• CPU Architecture: Any
• Tags: PreparedStatement, timestamp

[20 Jul 2010 13:13] Roman Bednarek

Description:
Function setTimestamp in PreparedStatement uses server timezone instead of jvm default when calendar parameter is ommited. With new time handling option useLegacyDatetimeCode=false.
Cite from docs "If no Calendar object is specified, the driver uses the default timezone, which is that of the virtual machine running the application."

How to repeat:
see testcase

[20 Jul 2010 13:14] Roman Bednarek

sql to create table for testcase

Attachment: bug55398.sql (application/octet-stream, text), 107 bytes.

[20 Jul 2010 13:15] Roman Bednarek

simple testcase

Attachment: bug55398.java (text/x-java-source), 1.61 KiB.

[20 Jul 2010 13:25] Tonci Grgin

Roman, what happens with useServerPrepStmts=true?

[20 Jul 2010 13:32] Roman Bednarek

With useServerPrepStmts=true, the result is different. 
all three result are the same:

with utc calendar:
2010-07-01 02:00:00.0
with local calendar:
2010-07-01 02:00:00.0
without calendar:
2010-07-01 02:00:00.0

without useServerPrepStmts=true:

with utc calendar:
2010-07-01 02:00:00.0
with local calendar:
without calendar:
2010-07-01 02:00:00.0

and according to documentation it should be:
with utc calendar:
2010-07-01 02:00:00.0
with local calendar:
without calendar:

[20 Jul 2010 13:53] Tonci Grgin

Roman, the two types of PSTMT should operate the same so this is a bug.

[25 Apr 2013 8:34] Alexander Soklakov

Bug#68063 is duplicate of this one, reporting different behavior of CSPS and SSPS.

[28 Jun 2021 12:17] Alexander Soklakov

Fixed as a part of date-time refactoring under Bug#95644.