Comment 1 Tom Ware 2010-06-14 14:27:38 EDT

Requires triage for 2.1.1

Comment 2 Peter Krogh 2010-07-26 08:54:59 EDT

Defferring to 2.2.0 for 2.1.1 closedown.

Comment 3 Andrei Ilitchev 2010-11-10 17:24:24 EST

So far I could not reproduce the issue.

Convertion from util.Date to sql.Date is performed before executing sql, so it's not a driver problem.

Could you please run the following simple test and see if it can reproduce the problem and if so debug into sqlDateFromUtilDate to see what's going on:
            java.util.Date utilDate = ...
            System.out.println("utilDate = " + utilDate);
            java.sql.Date sqlDate = org.eclipse.persistence.internal.helper.Helper.sqlDateFromUtilDate(utilDate);
            System.out.println("sqlDate = " + sqlDate);

Comment 4 Andrei Ilitchev 2010-11-16 14:37:29 EST

I can't reproduce the issue.

Comment 5 Ari Meyer 2010-11-23 05:42:43 EST

Hi Andrei,

Apologies for the delay -- I don't check this email acct often, and I've changed the acct now.  I ran my test (setting the field to @Temporal(TemporalType.DATE)) with your debugging statements (printing both before and after em.persist() to see if there was any diff), and got the same incorrect results as before.  The date values stored in Oracle were, likewise, incorrect.  Code:

java.util.Date utilDate = aBudgetRsrcCurve.getPeriodStart();
System.out.println("utilDate (BEFORE PERSIST) = " + utilDate);
java.sql.Date sqlDate = org.eclipse.persistence.internal.helper.Helper.sqlDateFromUtilDate(utilDate);
System.out.println("sqlDate (BEFORE PERSIST) = " + sqlDate);

_entityManager.persist(aBudgetRsrcCurve);
//	_logger.debug("BudgetRsrcCurve = " + aBudgetRsrcCurve);

utilDate = aBudgetRsrcCurve.getPeriodStart();
System.out.println("utilDate (AFTER PERSIST) = " + utilDate);
sqlDate = org.eclipse.persistence.internal.helper.Helper.sqlDateFromUtilDate(utilDate);
System.out.println("sqlDate (AFTER PERSIST) = " + sqlDate);


sample output:

utilDate (BEFORE PERSIST) = Wed Oct 01 00:00:00 GMT-08:00 2003
sqlDate (BEFORE PERSIST) = 2003-09-30
[2010-11-23 02:11:41,515] DEBUG mil.army.usace.p2.util.Utils user ID = u4iesabm
[2010-11-23 02:11:41,530] DEBUG mil.army.usace.p2.entity.AuditListener Auditing model on prepersist: mil.army.usace.p2.entity.BudgetRsrcCurve@10a6723[
  taskrsrcId=11362
  periodStart=Wed Oct 01 00:00:00 GMT-08:00 2003
  budgetType=DRAFT
  projectId=748
  taskId=105758
  periodUnits=0
  periodCost=0
  atCompletionUnits=0
  atCompletionCost=0
  mil.army.usace.p2.entity.BudgetRsrcCurve@10a6723[
  createUser=u4iesabm
  createDate=Tue Nov 23 02:11:41 GMT-08:00 2010
  updateUser=<null>
  updateDate=<null>
]
]
utilDate (AFTER PERSIST) = Wed Oct 01 00:00:00 GMT-08:00 2003
sqlDate (AFTER PERSIST) = 2003-09-30


When I set the field back to @Temporal(TemporalType.TIMESTAMP), the output was exactly the same:

utilDate (BEFORE PERSIST) = Wed Oct 01 00:00:00 GMT-08:00 2003
sqlDate (BEFORE PERSIST) = 2003-09-30
[2010-11-23 02:29:15,513] DEBUG mil.army.usace.p2.util.Utils user ID = u4iesabm
[2010-11-23 02:29:15,528] DEBUG mil.army.usace.p2.entity.AuditListener Auditing model on prepersist: mil.army.usace.p2.entity.BudgetRsrcCurve@1a66c87[
  taskrsrcId=11362
  periodStart=Wed Oct 01 00:00:00 GMT-08:00 2003
  budgetType=DRAFT
  projectId=748
  taskId=105758
  periodUnits=0
  periodCost=0
  atCompletionUnits=0
  atCompletionCost=0
  mil.army.usace.p2.entity.BudgetRsrcCurve@1a66c87[
  createUser=u4iesabm
  createDate=Tue Nov 23 02:29:15 GMT-08:00 2010
  updateUser=<null>
  updateDate=<null>
]
]
utilDate (AFTER PERSIST) = Wed Oct 01 00:00:00 GMT-08:00 2003
sqlDate (AFTER PERSIST) = 2003-09-30


... but the date values stored in Oracle were correct this time -- all first of the month and no rounding down.  It appears that Helper.sqlDateFromUtilDate(utilDate) is rounding the date down consistently, at least in my tests.

Thanks,
Ari

Comment 6 Ari Meyer 2010-11-23 06:07:40 EST

Looking deeper, it appears to be an issue of the timezone being converted from GMT to local.  Should the internally used Helper.dateFromCalendar(Calendar calendar) be converting it from its original timezone?  I can understand arguments both for and against this.  Unfortunately, in my case, my source date was not really meant to be Wed Oct 01 00:00:00 GMT-08:00 2003, but just Oct 1, 2003, in whatever the local timezone happens to be.

Given all this, do I really need to convert such dates to my local timezone and adjust them accordingly before setting them the JPA entity in order to avoid seeing these apparent inconsistencies?

Thanks,
Ari

Comment 7 Andrei Ilitchev 2010-11-23 13:35:39 EST

I believe it's not a bug.

Helper.sqlDateFromUtilDate is method used to convert util.Date to sql.Date. The result sql.Date should not have hours/mins/secs (otherwise two sql.Dates corresponding to the same date won't be equal - comparison is done based on longTime). So the only way to get rid of hours/mins/secs is to use Calendar in default time zone (no time zone could be extracted from util.Date - the one printed out is the default time zone).

You should be ok if you either:
always create and process util.Dates in default time zone;
or:
always set default time zone to the same zone - no matter where the app runs.

If that is not acceptible then I would use Temporal.TIMESTAMP (there is no conversion (created Timestamp has the same long time as the source util.Date).

Finally you can define your own converter:
   @Id
    @Column(name="PERIOD_START")
    @Convert("DateConverter")
    @Converter(
        name="DateConverter",
        converterClass=myPackage.MyDateConverter.class
    )
    private Date periodStart;

where converter class looks like:
public class MyDateConverter implements org.eclipse.persistence.mappings.converters.Converter {
    public MyDateConverter() {}
    
    public Object convertDataValueToObjectValue(Object dataValue, Session session) {
        if (dataValue != null) {
	  return new java.util.Date(((java.sql.Date)dataValue).getTime());
        }        
        return null;
    }
    
    public Object convertObjectValueToDataValue(Object objectValue, Session session) {
        if (objectValue != null) {
	  return new java.sql.Date(((java.util.Date)dataValue).getTime());
        }        
        return null;
    }

Comment 8 Ari Meyer 2010-11-26 21:15:41 EST

Thanks, Andrei -- that's what I figured.  I'll just leave it as a TIMESTAMP.  I'm just glad the mystery has been resolved.  Feel free to close this.

Best,
Ari

Comment 9 Ari Meyer 2010-11-26 21:51:22 EST

Minor clarification: the date that I was persisting was midnight in the local timezone, which was then converted to GMT (default timezone) before being truncated, not the other way around as I first stated.  In any case, all good now -- thanks!

Comment 10 Ari Meyer 2010-11-27 05:36:44 EST

Sorry for belaboring this, but I revisited the results, and now I'm more confused. ;-)  Just to be certain I wasn't misreading the output, I added a line to print utilDate.toGMTString():

utilDate (BEFORE PERSIST) = Wed Oct 01 00:00:00 GMT-08:00 2003
utilDate GMT (BEFORE PERSIST) = 1 Oct 2003 08:00:00 GMT
sqlDate (BEFORE PERSIST) = 2003-09-30

So sure enough, the original utilDate was already in my local ("default") timezone, PST.  Converting to GMT could only adjust the time forward (to 8:00AM GMT), not backward.  Why, then, is any conversion made at all when truncating it to a java.sql.Date, since the timezone should not have changed?  And how could any conversion have moved the time backward so that the resulting sqlDate is 09-30 instead of 10-01?  Please explain.

Thanks,
Ari

Comment 11 Chris Delahunt 2010-11-29 12:08:08 EST

Hello Ari,

The Date toString calls seem to indicate that the Calendar's being used are in the GMT-08:00, while the Helper.sqlDateFromUtilDate return value indicates that it is using a Calendar without a timezone set (ie 1 Oct 2003 GMT converted into PST is 2003-09-30).  

To confirm, can you print off:
  System.out.println("calendar in helper: "+org.eclipse.persistence.internal.helper.Helper.allocateCalendar());
        System.out.println("timezone in helper: "+org.eclipse.persistence.internal.helper.Helper.getDefaultTimeZone());
  System.out.println(" JVM default Calendar is: "+java.util.Calendar.getInstance());
  System.out.println(" JVM default timezone is: "+TimeZone.getDefault());

Are you changing the default Timezone anywhere in your application after the EclipseLink classes might have been loaded? Ie calling TimeZone.setDefault?

Comment 12 Ari Meyer 2010-12-01 03:33:21 EST

Hi Chris,

I'm definitely not changing the default timezone explicitly, and PST is what my timezone is set to on my PC.  Just to confirm, looking in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation (where the JVM apparently reads it from), it says:
StandardName = Pacific Standard Time

Here's the additional output:
calendar in helper: java.util.GregorianCalendar[time=1291185381903,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=10,WEEK_OF_YEAR=49,WEEK_OF_MONTH=5,DAY_OF_MONTH=30,DAY_OF_YEAR=334,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=10,HOUR_OF_DAY=22,MINUTE=36,SECOND=21,MILLISECOND=903,ZONE_OFFSET=-28800000,DST_OFFSET=0]
timezone in helper: sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
 JVM default Calendar is: java.util.GregorianCalendar[time=1291185571684,areFieldsSet=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=2010,MONTH=10,WEEK_OF_YEAR=49,WEEK_OF_MONTH=5,DAY_OF_MONTH=30,DAY_OF_YEAR=334,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=10,HOUR_OF_DAY=22,MINUTE=39,SECOND=31,MILLISECOND=684,ZONE_OFFSET=-28800000,DST_OFFSET=0]
 JVM default timezone is: sun.util.calendar.ZoneInfo[id="GMT-08:00",offset=-28800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

utilDate = Wed Oct 01 00:00:00 GMT-08:00 2003
utilDate GMT = 1 Oct 2003 08:00:00 GMT
sqlDate = 2003-09-30


The other strange thing is that approx. 2/3 of the sqlDate conversions are correct, like below:

calendar in helper: java.util.GregorianCalendar[time=1291185397809,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=10,WEEK_OF_YEAR=49,WEEK_OF_MONTH=5,DAY_OF_MONTH=30,DAY_OF_YEAR=334,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=10,HOUR_OF_DAY=22,MINUTE=36,SECOND=37,MILLISECOND=809,ZONE_OFFSET=-28800000,DST_OFFSET=0]
timezone in helper: sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
 JVM default Calendar is: java.util.GregorianCalendar[time=1291185571715,areFieldsSet=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=2010,MONTH=10,WEEK_OF_YEAR=49,WEEK_OF_MONTH=5,DAY_OF_MONTH=30,DAY_OF_YEAR=334,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=10,HOUR_OF_DAY=22,MINUTE=39,SECOND=31,MILLISECOND=715,ZONE_OFFSET=-28800000,DST_OFFSET=0]
 JVM default timezone is: sun.util.calendar.ZoneInfo[id="GMT-08:00",offset=-28800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
 
utilDate = Sat Nov 01 00:00:00 GMT-08:00 2003
utilDate GMT = 1 Nov 2003 08:00:00 GMT
sqlDate = 2003-11-01

I don't see anything obviously different between the raw values for utilDate for Oct. and Nov. that would round one of them down and leave the other at the first of the month.  However, I did notice that 'timezone in helper' has "dstSavings=3600000,useDaylight=true", while 'JVM default timezone' shows "dstSavings=0,useDaylight=false", but this is the same for both cases.  In any case, the DST attributes for 'timezone in helper' are incorrect.

Do you see anything here that could be causing these inconsistent results?

Thanks,
Ari

Comment 13 Chris Delahunt 2010-12-01 09:43:14 EST

The difference between the two timezones is that one is using daylight savings while the other is not, which explains why it will work for most times and only have problems on 2 days a year, though only going back an hour will make a difference to dates.  

EclipseLink Calendar and TimeZone is obtained from the JVM statically when the class gets loaded, so at some point after start up the JVM's timezone is being changed.  Because EclipseLink cached the timezone/calendar, this change is not reflected into EclipseLink conversions.  I would like to close this bug with the original status and open a new one to get api added to allow changing the Timezone/Calendars to use for conversions since there doesn't seem to be a way to do that now.

As to why the JVM's timezone is changing - I cannot say other than it is.  EclipseLink calls 
protected static TimeZone defaultTimeZone = TimeZone.getDefault();  so at some point the default is being changed to the GMT-8 instead of PST.  Possibly a webserver change is overriding the system default?

Comment 14 Ari Meyer 2010-12-02 07:44:37 EST

Hi Chris,

I'm running these tests locally from the command line, so I'm not sure what is causing the default timezone to change, but I see that you're right -- somehow it is changing.  I am now printing out the info at the beginning:
calendar in helper: java.util.GregorianCalendar[time=1291292678738,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=336,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=4,HOUR_OF_DAY=4,MINUTE=24,SECOND=38,MILLISECOND=738,ZONE_OFFSET=-28800000,DST_OFFSET=0]
timezone in helper: sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
 JVM default Calendar is: java.util.GregorianCalendar[time=1291292698551,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=336,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=4,HOUR_OF_DAY=4,MINUTE=24,SECOND=58,MILLISECOND=551,ZONE_OFFSET=-28800000,DST_OFFSET=0]
 JVM default timezone is: sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]

But after the first call to the Primavera (project mgmt software) API, the test output changes:
calendar in helper: java.util.GregorianCalendar[time=1291292678738,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2010,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=336,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=4,HOUR_OF_DAY=4,MINUTE=24,SECOND=38,MILLISECOND=738,ZONE_OFFSET=-28800000,DST_OFFSET=0]
timezone in helper: sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
 JVM default Calendar is: java.util.GregorianCalendar[time=1291292869707,areFieldsSet=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=2010,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=336,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=4,HOUR_OF_DAY=4,MINUTE=27,SECOND=49,MILLISECOND=707,ZONE_OFFSET=-28800000,DST_OFFSET=0]
 JVM default timezone is: sun.util.calendar.ZoneInfo[id="GMT-08:00",offset=-28800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

I guess Primavera must be changing the default timezone internally, but I can't see their source code to verify this.  In any case, thanks for solving the puzzle.  I'll just leave the mapping as TIMESTAMP for now.  You can close this bug.

Thanks,
Ari

Comment 15 Eclipse Webmaster 2022-06-09 10:31:47 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink