Thanks guys for your help. After tinkering with the problem for a bit I
decided that it was safer to store the date as a long (BIGINT) value,
the number of milliseonds since 1970 or so. Then I can be sure which
time it is!
John.
Greg Monroe wrote:
Hmm, I think I found where this is happening but am not sure how to fix
it. This
may be different in the current RC but the problem looks to be is in the
Village
Value object.
Date fields in the generated Peer object's populateObject method, use:
row.getValue(offset+#).asUtilDate()
to get the date object. In the Value.asUtilDate() method, there is a
call to
Calendar.getInstance() to create an object used in creating the Date
object returned.
The getInstance() method will use the default locale... hence, the BST
vs UTC problem.
The Value class in the Village code stream could be patched to fix this,
but since
Village is another (very quiet) project, it's probably not a good thing.
I know
there has been talk/coding toward getting rid of the Village
dependencies but I'm
not sure of the status of these.
If possible, the short term fix might be to make sure your Java apps
default time
zone matches your DB's time zone. (I KNOW!... major kludge... but if it
works...)
I'm not really sure why Village is using a Calendar object to repackage
the good
Date object that is returned by the JDBC native code. Probably like
most bad
date code, it's due to someone who got confused by Sun's confusing
implimentation.
(I speaks from experience with coding shared calendars that people
across the world
used...dates and timezones and leap stuff is never simple as it seems.)
Good luck.
Greg
-----Original Message-----
From: John Dunne
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.
Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are
confidential communication or may otherwise be privileged or confidential and
are intended solely for the individual or entity to whom they are addressed.
If you are not the intended recipient you may not rely on the contents of this
email or any attachments, and we ask that you please not read, copy or
retransmit this communication, but reply to the sender and destroy the email,
its contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is strictly
prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
