Although the second solution is probably asking for trouble... when
you read stored dates back they'll require a conversion again.
Also Cayenne 3.0 introduces persistence of Calendar primitives via a
special ExtendedType [1]. This should be easy to port to 1.2 ...
although I am not sure it does the right thing regarding the time
zone either. I suspect we should be using
"PreparedStatement.setTimestamp(int,Timestamp,Calendar)" for it to
work. In any event, if you could write a straight JDBC test using
this form of "setTimestamp" method on your database and see how that
works, I'd appreciate feedback.
[1] https://svn.apache.org/repos/asf/incubator/cayenne/main/trunk/
core/cayenne-jdk1.4/src/main/java/org/apache/cayenne/access/types/
CalendarType.java
Andrus
On Dec 11, 2006, at 1:53 PM, Andrus Adamchik wrote:
> Yeah, daylight saving time is tricky... Though the Date object
> still stores information about the timezone. I am surprised the
> driver doesn't account for it. Here is a few options that you have:
>
> 1. [the simplest] If you can redesign your database, I'd suggest
> storing dates as long numbers.
> 2. "Normalize" dates as "pseudo-UTC" (i.e. subtracting an absolute
> difference with UTC, that should take into account the daylight
> saving time):
>
> Calendar cal1 = new GregorianCalendar();
> cal1.setTime(date1);
> int offsetMinutes = -(cal1.get(Calendar.ZONE_OFFSET) + cal1.get
> (Calendar.DST_OFFSET)) / (60 * 1000);
>
> But again, I am surprised that driver doesn't do that for you - may
> require more research with your DB...
>
> Andrus
This archive was generated by hypermail 2.0.0 : Mon Dec 11 2006 - 07:01:48 EST