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
