Thanks Malcolm,
I believe the odd conversion I'm seeing lies with Torque since when I
read in a table row, the java.util.Date object I get back for the
DATETIME column is GMT British Summer Time which is incorrect since the
mysql database is storing the time value as UTC. I believe (correct me
if I'm wrong ayone!) Torque is confused to as what timezone the value it
read should be and assumed it to be the same as Java's default TimeZone
(which is currently GMT britishsummertime) resulting in the time
shifting by an hour (equal to the offset for british summer time) when
it is saved. Also, the long values are different just before save and on
retrival.
So, is it possible to inform Torque that a DATETIME value it reads from
a database is of a particular timezone?
Thanks,
John.
Malcolm Kendall wrote:
Hi John,
Sounds like a display problem. Have you compared the long time value
just before save and on retrieval.
I would check the locale settings for the client and server.
Regards,
Malcolm Kendall
John Dunne wrote:
Hi All
I'm experiencing a taxing problem I've not been able to find a
solution to on google!
I've got a table with some DATETIME columns present. Whenever I call
save, the DATETIME column value gets put back by an hour. I'm
guessing that torque is converting the value from UTC to GMT (or vice
versa) but I've not found a way to alter this behaviour. Any ideas?
Thanks in advance,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
