Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » bizarre DATE adjustment during binding
bizarre DATE adjustment during binding [message #530225] Wed, 28 April 2010 23:03 Go to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Hi,

I'm doing a batch insert with Eclipselink 2.0.2, Oracle JDBC driver
ojdbc5.jar 11.1.0.6.0, and running Oracle 10.2.0.4.0 DB. I've annotated
a java.util.Date with @Temporal(TemporalType.DATE):

@Id
@Column(name="PERIOD_START")
@Temporal(TemporalType.DATE)
private Date periodStart;

The date is part of the PK, and date values have no time component. For
about half of the inserts the binding is correct, but others are
strangely bound to the day prior:

[EL Fine]: 2010-04-28
16:15:09.406--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--INSERT
INTO BUDGET_RSRC_CURVE (PERIOD_START, TASKRSRC_ID, BUDGET_TYPE_ID,
TASK_ID, PERIOD_UNITS, DELETE_DATE, AT_COMPLETION_UNITS, PROJ_ID,
UPDATE_DATE, CREATE_USER, PERIOD_COST, AT_COMPLETION_COST, DELETE_USER,
CREATE_DATE, UPDATE_USER) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?)
[EL Fine]: 2010-04-28
16:15:09.453--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2004-08-31, 142719, 2, 35899,
1.517642240537477871242799665196798741817474365234375, null,
16.64731756756756198001312441192567348480224609375, 747, null, P2_USER,
2.435444011444863665616367143229581415653228759765625,
26.71486611486485429622916853986680507659912109375, null, 2010-04-28
15:12:53.515, null]
[EL Fine]: 2010-04-28
16:15:09.453--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2009-05-31, 3357792, 2, 3042074, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:14:01.515, null]
[EL Fine]: 2010-04-28
16:15:12.921--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2008-01-01, 1118702, 2, 2335339, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:12:54.656, null]
[EL Fine]: 2010-04-28
16:15:12.921--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2005-02-01, 1118813, 2, 2335339, 0, null,
0.0481197860962566947851115628509433008730411529541015625, 747, null,
P2_USER, 0, 4.81197860962566892339964397251605987548828125, null,
2010-04-28 15:12:57.375, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2007-10-31, 8048557, 2, 9036580, 0, null,
4.47829090909090954397697714739479124546051025390625, 747, null,
P2_USER, 0, 447.8290909090909508449840359389781951904296875, null,
2010-04-28 15:14:34.968, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2008-12-01, 1727942, 2, 3042043, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:13:31.015, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2008-07-31, 1118715, 2, 2335339, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:12:54.796, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2007-10-31, 8922414, 2, 9713611, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:14:39.093, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2009-01-01, 1727940, 2, 3042043, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:13:29.031, null]
[EL Fine]: 2010-04-28
16:15:12.937--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2006-03-01, 1118893, 2, 2334983,
14.838689732943915799978640279732644557952880859375, null,
13.87078839178081324234881321899592876434326171875, 747, null, P2_USER,
1558.062421959111134128761477768421173095703125,
1456.43278113698534070863388478755950927734375, null, 2010-04-28
15:13:13.64, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2004-12-01, 3260300, 2, 2335047, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:13:48.093, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2005-02-01, 6659, 2, 35978, 0, null, 0, 747, null, P2_USER, 0,
0, null, 2010-04-28 15:12:47.843, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2007-09-30, 1118717, 2, 2335339, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:12:55.078, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2007-09-30, 1118838, 2, 2334984, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:13:02.765, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2008-06-30, 1118814, 2, 2335339, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 15:12:57.625, null]
[EL Fine]: 2010-04-28
16:15:12.953--ClientSession(26440262)--Connection(20153007)- -Thread(Thread[main,5,main])--
bind => [2009-02-01, 8166315, 2, 2334983,
0.49032192161031940003113049897365272045135498046875, null, 0, 747,
null, P2_USER, 49.0321921610319435558267286978662014007568359375, 0,
null, 2010-04-28 15:14:37.031, null]
.....
.....


However, when I changed the mapping to use TemporalType.TIMESTAMP, it
binds correctly always:

[EL Fine]: 2010-04-28
17:11:03.506--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--INSERT
INTO BUDGET_RSRC_CURVE (PERIOD_START, TASKRSRC_ID, BUDGET_TYPE_ID,
TASK_ID, PERIOD_UNITS, DELETE_DATE, AT_COMPLETION_UNITS, PROJ_ID,
UPDATE_DATE, CREATE_USER, PERIOD_COST, AT_COMPLETION_COST, DELETE_USER,
CREATE_DATE, UPDATE_USER) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?)
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2008-01-01 00:00:00.0, 6192516, 2, 7509227,
4.6675985656858554051495957537554204463958740234375, null, 0, 747, null,
P2_USER, 583.449820710731955841765739023685455322265625, 0, null,
2010-04-28 16:10:23.581, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2006-01-01 00:00:00.0, 3260294, 2, 2335047, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:07:30.036, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-02-01 00:00:00.0, 4234621, 2, 2334985,
0.12251197917296341444171048351563513278961181640625, null, 0, 747,
null, P2_USER, 12.251197917296341444171048351563513278961181640625, 0,
null, 2010-04-28 16:09:28.921, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2010-10-01 00:00:00.0, 8166315, 2, 2334983,
0.5161283385371806531338734203018248081207275390625, null, 0, 747, null,
P2_USER, 51.61283385371806531338734203018248081207275390625, 0, null,
2010-04-28 16:10:50.271, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-06-01 00:00:00.0, 1118717, 2, 2335339, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:05:36.171, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2005-09-01 00:00:00.0, 6652, 2, 35900, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 16:05:09.593, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2005-01-01 00:00:00.0, 1118644, 2, 2335336,
0.0025919990928003179900263042156893789069727063179016113281 25, null, 0,
747, null, P2_USER, 15.55199455680190823159136925823986530303955078125,
0, null, 2010-04-28 16:05:25.828, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-05-01 00:00:00.0, 1118815, 2, 2335339, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:05:40.75, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-04-01 00:00:00.0, 3260301, 2, 2335047, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:07:43.881, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-11-01 00:00:00.0, 3447331, 2, 4886278, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:09:12.279, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-12-01 00:00:00.0, 5776433, 2, 2335985, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:09:50.61, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2007-07-01 00:00:00.0, 6642, 2, 35899, 0, null, 0, 747, null,
P2_USER, 0, 0, null, 2010-04-28 16:05:06.453, null]
[EL Fine]: 2010-04-28
17:11:05.069--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2005-10-01 00:00:00.0, 2677691, 2, 2335033, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:06:53.534, null]
[EL Fine]: 2010-04-28
17:11:05.084--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2005-11-01 00:00:00.0, 3260294, 2, 2335047, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:07:30.036, null]
[EL Fine]: 2010-04-28
17:11:05.084--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2006-05-01 00:00:00.0, 1118847, 2, 2334984, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:06:03.546, null]
[EL Fine]: 2010-04-28
17:11:05.084--ClientSession(16843259)--Connection(19478135)- -Thread(Thread[main,5,main])--
bind => [2008-02-01 00:00:00.0, 1814180, 2, 3129496, 0, null, 0, 747,
null, P2_USER, 0, 0, null, 2010-04-28 16:06:43.142, null]


Any ideas why we're seeing these inconsistencies with TemporalType.DATE?
I thought it might be a problem with the Oracle JDBC driver, but I
tried with the latest ojdbc6.jar and got the same results.

Note that I've also set the following properties, as recommended for
batch inserts according to
http://forums.oracle.com/forums/thread.jspa?messageID=382956 5 (though I
got the same results without eclipselink.jdbc.batch-writing set):

<property name="eclipselink.jdbc.batch-writing" value="JDBC"/>
<property name="eclipselink.cache.shared.default" value="false"/>

Since it works correctly with TemporalType.TIMESTAMP, we're fine, but
I'd like to know why it's not working consistently with TemporalType.DATE.

Thanks,
Ari
Re: bizarre DATE adjustment during binding [message #530346 is a reply to message #530225] Thu, 29 April 2010 13:01 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1389
Registered: July 2009
Senior Member
Hello,

Which JDK are you using? I noticed a strange issue with calendar conversions when using an early JDK 1.6.0 build, causing problems inserting dates since it would shift milliseconds by one or two. They went away when I switched to using jdk 1.6.0_17. You might not be getting the problem when you use a timestamp temporal type if you are using a timestamp in your object since no conversion is neccessary. Try using a timestamp temporal type on a calendar so you can see if the milliseconds are off or not.

Best Regards,
Chris
Re: bizarre DATE adjustment during binding [message #530868 is a reply to message #530346] Sun, 02 May 2010 06:49 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Hi Chris,

I'm running the latest 1.6.0_20, so unless there's been a regression,
the JDK version is not the issue. Will test with a Calendar and let you
know how it goes.

Thanks,
Ari

Chris Delahunt wrote:
> Hello,
>
> Which JDK are you using? I noticed a strange issue with calendar
> conversions when using an early JDK 1.6.0 build, causing problems
> inserting dates since it would shift milliseconds by one or two. They
> went away when I switched to using jdk 1.6.0_17. You might not be
> getting the problem when you use a timestamp temporal type if you are
> using a timestamp in your object since no conversion is neccessary. Try
> using a timestamp temporal type on a calendar so you can see if the
> milliseconds are off or not.
> Best Regards,
> Chris
Re: bizarre DATE adjustment during binding [message #531459 is a reply to message #530868] Wed, 05 May 2010 06:11 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Hey Chris,

I ran the test using Calendar with @Temporal(TemporalType.TIMESTAMP),
and I don't see any milliseconds off -- everything looks fine. On
@PrePersist, the logs show data like:

periodStart=java.util.GregorianCalendar[time=1214899200000,a reFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun. util.calendar.ZoneInfo[id= "GMT-08:00" ,offset=-28800000,dstSavings=0,useDaylight=false,transitions =0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1, ERA=1,YEAR=2008,MONTH=6,WEEK_OF_YEAR=27,WEEK_OF_MONTH=1,DAY_ OF_MONTH=1,DAY_OF_YEAR=183,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONT H=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECO ND=0,ZONE_OFFSET=-28800000,DST_OFFSET=0]

all records show: MILLISECOND=0


Using Calendar with @Temporal(TemporalType.DATE) gives the same
inconsistencies as java.util.Date does.

Any ideas? I'm fine using @Temporal(TemporalType.TIMESTAMP), but
there's definitely something wrong if I can't use
@Temporal(TemporalType.DATE) in this situation.

Thanks again,
Ari

Ari Meyer wrote:
> Hi Chris,
>
> I'm running the latest 1.6.0_20, so unless there's been a regression,
> the JDK version is not the issue. Will test with a Calendar and let you
> know how it goes.
>
> Thanks,
> Ari
>
> Chris Delahunt wrote:
>> Hello,
>>
>> Which JDK are you using? I noticed a strange issue with calendar
>> conversions when using an early JDK 1.6.0 build, causing problems
>> inserting dates since it would shift milliseconds by one or two. They
>> went away when I switched to using jdk 1.6.0_17. You might not be
>> getting the problem when you use a timestamp temporal type if you are
>> using a timestamp in your object since no conversion is neccessary.
>> Try using a timestamp temporal type on a calendar so you can see if
>> the milliseconds are off or not. Best Regards,
>> Chris
Re: bizarre DATE adjustment during binding [message #531465 is a reply to message #531459] Wed, 05 May 2010 06:23 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Also, just to be thorough, the output of the binding for Calendar with
@Temporal(TemporalType.TIMESTAMP) looks fine as well, with all the time
components showing 00:00:00.0:

[EL Fine]: 2010-05-04
18:45:22.328--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--INSERT
INTO BUDGET_RSRC_CURVE (PERIOD_START, TASKRSRC_ID, BUDGET_TYPE_ID,
TASK_ID, PERIOD_UNITS, AT_COMPLETION_UNITS, PROJ_ID, UPDATE_DATE,
CREATE_USER, PERIOD_COST, AT_COMPLETION_COST, CREATE_DATE, UPDATE_USER)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
[EL Fine]: 2010-05-04
18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2009-07-01 00:00:00.0, 1727948, 2, 3042045, 0, 0, 747, null,
P2_USER, 0, 0, 2010-05-04 17:45:09.046, null]
[EL Fine]: 2010-05-04
18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2008-06-01 00:00:00.0, 1727947, 2, 3042045, 0, 0, 747, null,
P2_USER, 0, 0, 2010-05-04 17:45:08.984, null]
[EL Fine]: 2010-05-04
18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2008-06-01 00:00:00.0, 1727936, 2, 3042043, 0, 0, 747, null,
P2_USER, 0, 0, 2010-05-04 17:45:07.343, null]
[EL Fine]: 2010-05-04
18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2007-03-01 00:00:00.0, 3758174, 2, 2335032, 0, 0, 747, null,
P2_USER, 0, 0, 2010-05-04 17:45:17.765, null]
[EL Fine]: 2010-05-04
18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2006-10-01 00:00:00.0, 5776433, 2, 2335985, 0, 0, 747, null,
P2_USER, 0, 0, 2010-05-04 17:45:19.296, null]
[EL Fine]: 2010-05-04
18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
bind => [2004-11-01 00:00:00.0, 1118653, 2, 2335337,
0.0054400027200013599537609110257108113728463649749755859375 , 0, 747,
null, P2_USER, 32.6400163200081578906974755227565765380859375, 0,
2010-05-04 17:45:03.25, null]

Regards,
Ari

Ari Meyer wrote:
> Hey Chris,
>
> I ran the test using Calendar with @Temporal(TemporalType.TIMESTAMP),
> and I don't see any milliseconds off -- everything looks fine. On
> @PrePersist, the logs show data like:
>
> periodStart=java.util.GregorianCalendar[time=1214899200000,a reFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun. util.calendar.ZoneInfo[id= "GMT-08:00" ,offset=-28800000,dstSavings=0,useDaylight=false,transitions =0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1, ERA=1,YEAR=2008,MONTH=6,WEEK_OF_YEAR=27,WEEK_OF_MONTH=1,DAY_ OF_MONTH=1,DAY_OF_YEAR=183,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONT H=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECO ND=0,ZONE_OFFSET=-28800000,DST_OFFSET=0]
>
>
> all records show: MILLISECOND=0
>
>
> Using Calendar with @Temporal(TemporalType.DATE) gives the same
> inconsistencies as java.util.Date does.
>
> Any ideas? I'm fine using @Temporal(TemporalType.TIMESTAMP), but
> there's definitely something wrong if I can't use
> @Temporal(TemporalType.DATE) in this situation.
>
> Thanks again,
> Ari
>
> Ari Meyer wrote:
>> Hi Chris,
>>
>> I'm running the latest 1.6.0_20, so unless there's been a regression,
>> the JDK version is not the issue. Will test with a Calendar and let
>> you know how it goes.
>>
>> Thanks,
>> Ari
>>
>> Chris Delahunt wrote:
>>> Hello,
>>>
>>> Which JDK are you using? I noticed a strange issue with calendar
>>> conversions when using an early JDK 1.6.0 build, causing problems
>>> inserting dates since it would shift milliseconds by one or two.
>>> They went away when I switched to using jdk 1.6.0_17. You might not
>>> be getting the problem when you use a timestamp temporal type if you
>>> are using a timestamp in your object since no conversion is
>>> neccessary. Try using a timestamp temporal type on a calendar so you
>>> can see if the milliseconds are off or not. Best Regards,
>>> Chris
Re: bizarre DATE adjustment during binding [message #536695 is a reply to message #531465] Sun, 30 May 2010 01:47 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Should I log a bug for this, or is this considered expected behavior?
If it's to be expected, please add this to the docs.

Thanks,
Ari

Ari Meyer wrote:
> Also, just to be thorough, the output of the binding for Calendar with
> @Temporal(TemporalType.TIMESTAMP) looks fine as well, with all the time
> components showing 00:00:00.0:
>
> [EL Fine]: 2010-05-04
> 18:45:22.328--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--INSERT
> INTO BUDGET_RSRC_CURVE (PERIOD_START, TASKRSRC_ID, BUDGET_TYPE_ID,
> TASK_ID, PERIOD_UNITS, AT_COMPLETION_UNITS, PROJ_ID, UPDATE_DATE,
> CREATE_USER, PERIOD_COST, AT_COMPLETION_COST, CREATE_DATE, UPDATE_USER)
> VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
> [EL Fine]: 2010-05-04
> 18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2009-07-01 00:00:00.0, 1727948, 2, 3042045, 0, 0, 747, null,
> P2_USER, 0, 0, 2010-05-04 17:45:09.046, null]
> [EL Fine]: 2010-05-04
> 18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2008-06-01 00:00:00.0, 1727947, 2, 3042045, 0, 0, 747, null,
> P2_USER, 0, 0, 2010-05-04 17:45:08.984, null]
> [EL Fine]: 2010-05-04
> 18:45:22.343--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2008-06-01 00:00:00.0, 1727936, 2, 3042043, 0, 0, 747, null,
> P2_USER, 0, 0, 2010-05-04 17:45:07.343, null]
> [EL Fine]: 2010-05-04
> 18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2007-03-01 00:00:00.0, 3758174, 2, 2335032, 0, 0, 747, null,
> P2_USER, 0, 0, 2010-05-04 17:45:17.765, null]
> [EL Fine]: 2010-05-04
> 18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2006-10-01 00:00:00.0, 5776433, 2, 2335985, 0, 0, 747, null,
> P2_USER, 0, 0, 2010-05-04 17:45:19.296, null]
> [EL Fine]: 2010-05-04
> 18:45:22.375--ClientSession(10130611)--Connection(9995652)-- Thread(Thread[main,5,main])--
> bind => [2004-11-01 00:00:00.0, 1118653, 2, 2335337,
> 0.0054400027200013599537609110257108113728463649749755859375 , 0, 747,
> null, P2_USER, 32.6400163200081578906974755227565765380859375, 0,
> 2010-05-04 17:45:03.25, null]
>
> Regards,
> Ari
>
> Ari Meyer wrote:
>> Hey Chris,
>>
>> I ran the test using Calendar with @Temporal(TemporalType.TIMESTAMP),
>> and I don't see any milliseconds off -- everything looks fine. On
>> @PrePersist, the logs show data like:
>>
>> periodStart=java.util.GregorianCalendar[time=1214899200000,a reFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun. util.calendar.ZoneInfo[id= "GMT-08:00" ,offset=-28800000,dstSavings=0,useDaylight=false,transitions =0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1, ERA=1,YEAR=2008,MONTH=6,WEEK_OF_YEAR=27,WEEK_OF_MONTH=1,DAY_ OF_MONTH=1,DAY_OF_YEAR=183,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONT H=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECO ND=0,ZONE_OFFSET=-28800000,DST_OFFSET=0]
>>
>>
>> all records show: MILLISECOND=0
>>
>>
>> Using Calendar with @Temporal(TemporalType.DATE) gives the same
>> inconsistencies as java.util.Date does.
>>
>> Any ideas? I'm fine using @Temporal(TemporalType.TIMESTAMP), but
>> there's definitely something wrong if I can't use
>> @Temporal(TemporalType.DATE) in this situation.
>>
>> Thanks again,
>> Ari
>>
>> Ari Meyer wrote:
>>> Hi Chris,
>>>
>>> I'm running the latest 1.6.0_20, so unless there's been a regression,
>>> the JDK version is not the issue. Will test with a Calendar and let
>>> you know how it goes.
>>>
>>> Thanks,
>>> Ari
>>>
>>> Chris Delahunt wrote:
>>>> Hello,
>>>>
>>>> Which JDK are you using? I noticed a strange issue with calendar
>>>> conversions when using an early JDK 1.6.0 build, causing problems
>>>> inserting dates since it would shift milliseconds by one or two.
>>>> They went away when I switched to using jdk 1.6.0_17. You might not
>>>> be getting the problem when you use a timestamp temporal type if you
>>>> are using a timestamp in your object since no conversion is
>>>> neccessary. Try using a timestamp temporal type on a calendar so
>>>> you can see if the milliseconds are off or not. Best Regards,
>>>> Chris
Re: bizarre DATE adjustment during binding [message #536982 is a reply to message #536695] Mon, 31 May 2010 19:19 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1389
Registered: July 2009
Senior Member
I would recommend you file a bug if you can produce a small test case that shows the issue. I haven't seen the issue myself; util.Date-> sql.Date works fine for me, so the test case would help narrow down the conditions it is occuring under.

Best Regards,
Chris

[Updated on: Mon, 31 May 2010 19:20]

Report message to a moderator

Re: bizarre DATE adjustment during binding [message #537580 is a reply to message #536982] Thu, 03 June 2010 01:35 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Thanks Chris -- bug filed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=315523 . I will prepare a
test case this week and add it to the bug report.

Best,
Ari

Chris Delahunt wrote:
> I would recommend you file a bug if you can produce a small test case
> that shows the issue. I haven't seen the issue myself; util.Date->
> sql.Date works fine for me, so the test case would help narrow down the
> conditions it is occuring with.
> Best Regards,
> Chris
Previous Topic:General design question on polymorphic collections and querying
Next Topic:Delete from collection
Goto Forum:
  


Current Time: Thu Mar 28 19:04:00 GMT 2024

Powered by FUDForum. Page generated in 0.05287 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top