9 messages in com.mysql.lists.javaRe: Question about PreparedStatement....
FromSent OnAttachments
Shankar Unni21 Jan 2003 16:45 
Mark Matthews21 Jan 2003 19:54 
Shankar Unni22 Jan 2003 11:05 
Mark Matthews22 Jan 2003 11:08 
Mark Matthews22 Jan 2003 11:13 
Shankar Unni22 Jan 2003 11:29 
Mark Matthews22 Jan 2003 11:33 
Shankar Unni22 Jan 2003 11:57 
David Morse22 Jan 2003 13:35 
Subject:Re: Question about PreparedStatement.setTimestamp(..., Calendar)
From:Mark Matthews (ma@mysql.com)
Date:01/22/2003 11:33:55 AM
List:com.mysql.lists.java

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Shankar Unni wrote: [snip]

Right. It's what it does with this interpretation that's the issue.

What Oracle does is say "OK, you say the value you passed in is in UTC; OK, I'll do <dateformatter_with_UTC_Timezone>.format(yourValueInMilliseconds)", which gives an hour, minute, etc. values, and write that into the Oracle DATE column.

Whereas what MySQL seems to do is say "OK, your value is in UTC; the server is in PST, so I'll subtract 8 hours from your timestamp value, and then format it in the server's timezone". This is quite different from the above.

How are you retrieving it, though? If you use ResultSet.getTimestamp(n, a_gmt_calendar_instance), you should get back the exact same value. Otherwise it will be converted to the client's timezone (PST) when useTimezone=true.

Like I said, I'll open a bug in the Java Developer Connection to get a clarification on this, but for the moment, I have a driver-specific "adapter layer" between my application code and the JDBC calls (I need it for other cross-DB JDBC compatibility reasons), so I can handle these differences in the adapter layer..

Okay. Please let me know if they come up with an answer for you :)

-Mark - -- MySQL 2003 Users Conference -> http://www.mysql.com/events/uc2003/

For technical support contracts, visit https://order.mysql.com/?ref=mmma

iD8DBQE+LvI8tvXNTca6JD8RAn5uAKCDfFEs0jzhYkAZdIYtF7zf6pKzBACfaTHa o3YwxgNqMzL0HxuSJzM8zbY= =YmPz -----END PGP SIGNATURE-----