db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Dunne <imir...@alldunne.com>
Subject Re: DATEIME's value is adjusted by an hour without consent
Date Wed, 28 Sep 2005 08:32:23 GMT
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: torque-user-unsubscribe@db.apache.org
>For additional commands, e-mail: torque-user-help@db.apache.org
>
>
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message