Ok, although I was a moron since I wasn't passing the date to my DAO
and instead was having it create a date to pass in, even when fixed
I'm still having a fraction of a second off:
Date today = new Date();
log.info("Today time: "+ today.getTime() );
associateDAO.setLastLogin(TestConstants.ASSOCIATE_ID_RICK, today);
Associate associate =
associateDAO.findByAssociateID(TestConstants.ASSOCIATE_ID_RICK);
log.info("associate lastlogin time: "+
associate.getLastLoginDateTime().getTime() );
assert associate.getLastLoginDateTime().compareTo(today) == 0;
On Wed, Jan 28, 2009 at 3:43 PM, Rick <[email protected]> wrote:
> OMG please DELETE THREAD DELETE THREAD>
>
> RICK IS A MORON. RICK IS A MORON.
>
> IGNORE IGNORE IGNORE:)
>
> On Wed, Jan 28, 2009 at 3:38 PM, Rick <[email protected]> wrote:
>> Crap, now I seem to be having the issue with the jtds driver also.
>> Maybe I just get lucky sometimes and the dates just work. Most of the
>> time the time is off by a fraction of a second:
>>
>> These two times should match....
>>
>> 01/28/09 03:29:16 PM INFO
>> com.nielsen.ondp.test.persistence.dao.gui.AssociateTest setLastLogin -
>> Today time: 1233174556616
>> 01/28/09 03:29:16 PM INFO
>> com.nielsen.ondp.test.persistence.dao.gui.AssociateTest setLastLogin -
>> associate lastlogin time: 1233174556617
>>
>> Here's some relevant info:
>>
>> The test case:
>>
>> Date today = new Date();
>> log.info("Today time: "+ today.getTime() );
>> associateDAO.setLastLogin(TestConstants.ASSOCIATE_ID_RICK);
>> Associate associate =
>> associateDAO.findByAssociateID(TestConstants.ASSOCIATE_ID_RICK);
>> log.info("associate lastlogin time: "+
>> associate.getLastLoginDateTime().getTime() );
>> assert associate.getLastLoginDateTime().compareTo(today) == 0;
>>
>>
>> <update id="setLastLogin" parameterClass="java.util.HashMap">
>> update NPPAssociate set lastLoginDateTime = #lastLoginDateTime:DATETIME#
>> where associateID = #associateID#
>> </update>
>>
>> in the result map:
>>
>> <result column="lastLoginDateTime" property="lastLoginDateTime"
>> jdbcType="DATETIME" />
>>
>> Associate object has java.util.Date lastLoginDateTime
>>
>> I've tried TIMESTAMP in place of DATETIME, didn't seem to make a difference
>>
>>
>>
>> On Wed, Jan 28, 2009 at 3:08 PM, Rick <[email protected]> wrote:
>>> Maybe I'm setting things up wrong, but when I try to insert or update
>>> using java.util.Date the very last digit on the long of this datetime
>>> (date.getTime()) will be 1 fraction of second greater after either
>>> it's entered into the db or on the way out (I haven't investigated if
>>> it's on the way or n as the problem, but will shortly.)
>>>
>>> column is DATETIME, but regardless of driver my JDBC type I have to
>>> set to TIMESTAMP (although I tried DATETIME also)
>>>
>>> If I switch to the jtds sourceforge jar this issue seems to go away.
>>> Any ideas what I'm doing wrong so that I can get this to work
>>> correctly using jconnect?
>>>
>>>
>>> --
>>> Rick
>>>
>>
>>
>>
>> --
>> Rick
>>
>
>
>
> --
> Rick
>
--
Rick
