db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
Date Mon, 19 Apr 2010 11:02:50 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-4582:

    Attachment: derby-4582-1a-client-send.diff

Attached is a patch (derby-4582-1a-client-send.diff) that addresses
issue (1) described above. That is, sending of date, time and
timestamp from the client.

It makes the following changes:

A       java/client/org/apache/derby/client/am/DateTimeValue.java

New class that represents a Time, Date or Timestamp in a specified
calendar. This class preserves the representation of the time in the
specified calendar so that it's not affected by oddities in the local

M       java/client/org/apache/derby/client/am/PreparedStatement.java

Use the new DateTimeValue class to represent values set by setDate(),
setTime() and setTimestamp().

M       java/client/org/apache/derby/client/net/NetStatementRequest.java

Accept that date, time and timestamp are also set as DateTimeValue,
and convert values that still are represented by
java.sql.{Date,Time,Timestamp} to DateTimeValue using the default

M       java/client/org/apache/derby/client/am/DateTime.java
M       java/client/org/apache/derby/client/net/Request.java

Change signatures for the methods that write dates and times to expect
DateTimeValue instead of java.sql.{Date,Time,Timestamp}.

All the regression tests ran cleanly with the patch.

The patch reduces the number of failures from six to one in the
original repro. It makes the client driver send the correct values to
the server for all the timestamps, but because of (2) one of them is
stored incorrectly in the database.

One thing to note is that the patch now makes the client driver create
a new default calendar instance object each time one of the setters
with no calendar argument is called. We could easily cache a default
calendar instance in PreparedStatement to prevent this (like the
embedded driver already does), but in order to keep the patches
smaller and easier to review, I'd like to postpone that optimization
until after the bug has been fixed.

On the bright side, the methods that take calendar arguments used to
create two calendar instances, but now they don't create any.

> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT
calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-4582
>                 URL: https://issues.apache.org/jira/browse/DERBY-4582
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>         Environment: Windows XP Professional Version 2002 Service Pack 3,  Central Standard
Time Zone (America/Chicago)
>            Reporter: Keith Kruse
>            Assignee: Knut Anders Hatlen
>         Attachments: calendar.diff, derby-4582-1a-client-send.diff, DerbyTest.java, junit.diff,
junit.diff, upd-rs-test.diff
> This issue only appears to happen in Network Server/Client mode.  Embedded mode does
not have the issue.
> My timezone is American/Chicago.  Saving timestamps with values for the 6 hours prior
to DST start are being read back in as values 1 hour later than written.  (I believe the issue
happens on the write because values written in Network Server/Client mode and read in Embedded
mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps
1 hour off.  The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message