Derby
  1. Derby
  2. DERBY-4582

Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).

    Details

    • Urgency:
      Normal
    • Bug behavior facts:
      Embedded/Client difference, Wrong query result

      Description

      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);
      ...

      1. derby-4582-10.5.diff
        71 kB
        Lily Wei
      2. derby-4582-6a-javame.diff
        3 kB
        Knut Anders Hatlen
      3. derby-4582-5a-bugfix.diff
        3 kB
        Knut Anders Hatlen
      4. derby-4582-4a-client-receive.diff
        44 kB
        Knut Anders Hatlen
      5. derby-4582-3a-server-send.diff
        9 kB
        Knut Anders Hatlen
      6. derby-4582-2a-server-receive.diff
        9 kB
        Knut Anders Hatlen
      7. derby-4582-1a-client-send.diff
        24 kB
        Knut Anders Hatlen
      8. ASF.LICENSE.NOT.GRANTED--upd-rs-test.diff
        5 kB
        Knut Anders Hatlen
      9. ASF.LICENSE.NOT.GRANTED--junit.diff
        13 kB
        Knut Anders Hatlen
      10. junit.diff
        10 kB
        Knut Anders Hatlen
      11. calendar.diff
        17 kB
        Knut Anders Hatlen
      12. DerbyTest.java
        9 kB
        Keith Kruse

        Issue Links

          Activity

          Hide
          Keith Kruse added a comment -

          Thanks for looking at this!

          The test class has a "dbmode" enum variable that allows it to run in Client or Embedded mode. The error only happend in Client mode.

          I run the test in the America/Chicago time zone. The test timestamp data have to change to test in other timezones.

          I am including two sets of output from the test. The first set shows failure in client mode (search for *FAILED). The second set shows success in embedded mode.

          Database Mode: CLIENT
          Local Time Zone: Central Standard Time
          Using Client Driver: org.apache.derby.jdbc.ClientDriver
          Using Client URL: jdbc:derby://localhost:1527/C:\temp\dst_test_db;user=app;password=app;create=true
          Dropping Table...
          Creating Table...
          Mar 13, 2010 10:01:00 PM GMT (Mar 13, 2010 4:01:00 PM CST) ok -> (Mar 13, 2010 10:01:00 PM GMT) Wrote: 1268517660000 Read: 1268517660000
          Mar 13, 2010 11:01:00 PM GMT (Mar 13, 2010 5:01:00 PM CST) ok -> (Mar 13, 2010 11:01:00 PM GMT) Wrote: 1268521260000 Read: 1268521260000
          Mar 14, 2010 12:01:00 AM GMT (Mar 13, 2010 6:01:00 PM CST) ok -> (Mar 14, 2010 12:01:00 AM GMT) Wrote: 1268524860000 Read: 1268524860000
          Mar 14, 2010 1:01:00 AM GMT (Mar 13, 2010 7:01:00 PM CST) ok -> (Mar 14, 2010 1:01:00 AM GMT) Wrote: 1268528460000 Read: 1268528460000
          Mar 14, 2010 2:01:00 AM GMT (Mar 13, 2010 8:01:00 PM CST) *FAILED -> (Mar 14, 2010 3:01:00 AM GMT) Wrote: 1268532060000 Read: 1268535660000 Difference: 3600000
          Mar 14, 2010 3:01:00 AM GMT (Mar 13, 2010 9:01:00 PM CST) *FAILED -> (Mar 14, 2010 4:01:00 AM GMT) Wrote: 1268535660000 Read: 1268539260000 Difference: 3600000
          Mar 14, 2010 4:01:00 AM GMT (Mar 13, 2010 10:01:00 PM CST) *FAILED -> (Mar 14, 2010 5:01:00 AM GMT) Wrote: 1268539260000 Read: 1268542860000 Difference: 3600000
          Mar 14, 2010 5:01:00 AM GMT (Mar 13, 2010 11:01:00 PM CST) *FAILED -> (Mar 14, 2010 6:01:00 AM GMT) Wrote: 1268542860000 Read: 1268546460000 Difference: 3600000
          Mar 14, 2010 6:01:00 AM GMT (Mar 14, 2010 12:01:00 AM CST) *FAILED -> (Mar 14, 2010 7:01:00 AM GMT) Wrote: 1268546460000 Read: 1268550060000 Difference: 3600000
          Mar 14, 2010 7:01:00 AM GMT (Mar 14, 2010 1:01:00 AM CST) *FAILED -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268550060000 Read: 1268553660000 Difference: 3600000
          Mar 14, 2010 8:01:00 AM GMT (Mar 14, 2010 3:01:00 AM CDT) ok -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268553660000 Read: 1268553660000
          Mar 14, 2010 9:01:00 AM GMT (Mar 14, 2010 4:01:00 AM CDT) ok -> (Mar 14, 2010 9:01:00 AM GMT) Wrote: 1268557260000 Read: 1268557260000
          Mar 14, 2010 10:01:00 AM GMT (Mar 14, 2010 5:01:00 AM CDT) ok -> (Mar 14, 2010 10:01:00 AM GMT) Wrote: 1268560860000 Read: 1268560860000
          Dropping Table...

          Database Mode: EMBEDDED
          Local Time Zone: Central Standard Time
          Using Embedded Driver: org.apache.derby.jdbc.EmbeddedDriver
          Using Embedded URL: jdbc:derby:directory:C:\temp\dst_test_db;create=true
          Dropping Table...
          Creating Table...
          Mar 13, 2010 10:01:00 PM GMT (Mar 13, 2010 4:01:00 PM CST) ok -> (Mar 13, 2010 10:01:00 PM GMT) Wrote: 1268517660000 Read: 1268517660000
          Mar 13, 2010 11:01:00 PM GMT (Mar 13, 2010 5:01:00 PM CST) ok -> (Mar 13, 2010 11:01:00 PM GMT) Wrote: 1268521260000 Read: 1268521260000
          Mar 14, 2010 12:01:00 AM GMT (Mar 13, 2010 6:01:00 PM CST) ok -> (Mar 14, 2010 12:01:00 AM GMT) Wrote: 1268524860000 Read: 1268524860000
          Mar 14, 2010 1:01:00 AM GMT (Mar 13, 2010 7:01:00 PM CST) ok -> (Mar 14, 2010 1:01:00 AM GMT) Wrote: 1268528460000 Read: 1268528460000
          Mar 14, 2010 2:01:00 AM GMT (Mar 13, 2010 8:01:00 PM CST) ok -> (Mar 14, 2010 2:01:00 AM GMT) Wrote: 1268532060000 Read: 1268532060000
          Mar 14, 2010 3:01:00 AM GMT (Mar 13, 2010 9:01:00 PM CST) ok -> (Mar 14, 2010 3:01:00 AM GMT) Wrote: 1268535660000 Read: 1268535660000
          Mar 14, 2010 4:01:00 AM GMT (Mar 13, 2010 10:01:00 PM CST) ok -> (Mar 14, 2010 4:01:00 AM GMT) Wrote: 1268539260000 Read: 1268539260000
          Mar 14, 2010 5:01:00 AM GMT (Mar 13, 2010 11:01:00 PM CST) ok -> (Mar 14, 2010 5:01:00 AM GMT) Wrote: 1268542860000 Read: 1268542860000
          Mar 14, 2010 6:01:00 AM GMT (Mar 14, 2010 12:01:00 AM CST) ok -> (Mar 14, 2010 6:01:00 AM GMT) Wrote: 1268546460000 Read: 1268546460000
          Mar 14, 2010 7:01:00 AM GMT (Mar 14, 2010 1:01:00 AM CST) ok -> (Mar 14, 2010 7:01:00 AM GMT) Wrote: 1268550060000 Read: 1268550060000
          Mar 14, 2010 8:01:00 AM GMT (Mar 14, 2010 3:01:00 AM CDT) ok -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268553660000 Read: 1268553660000
          Mar 14, 2010 9:01:00 AM GMT (Mar 14, 2010 4:01:00 AM CDT) ok -> (Mar 14, 2010 9:01:00 AM GMT) Wrote: 1268557260000 Read: 1268557260000
          Mar 14, 2010 10:01:00 AM GMT (Mar 14, 2010 5:01:00 AM CDT) ok -> (Mar 14, 2010 10:01:00 AM GMT) Wrote: 1268560860000 Read: 1268560860000
          Dropping Table...

          Show
          Keith Kruse added a comment - Thanks for looking at this! The test class has a "dbmode" enum variable that allows it to run in Client or Embedded mode. The error only happend in Client mode. I run the test in the America/Chicago time zone. The test timestamp data have to change to test in other timezones. I am including two sets of output from the test. The first set shows failure in client mode (search for *FAILED). The second set shows success in embedded mode. Database Mode: CLIENT Local Time Zone: Central Standard Time Using Client Driver: org.apache.derby.jdbc.ClientDriver Using Client URL: jdbc:derby://localhost:1527/C:\temp\dst_test_db;user=app;password=app;create=true Dropping Table... Creating Table... Mar 13, 2010 10:01:00 PM GMT (Mar 13, 2010 4:01:00 PM CST) ok -> (Mar 13, 2010 10:01:00 PM GMT) Wrote: 1268517660000 Read: 1268517660000 Mar 13, 2010 11:01:00 PM GMT (Mar 13, 2010 5:01:00 PM CST) ok -> (Mar 13, 2010 11:01:00 PM GMT) Wrote: 1268521260000 Read: 1268521260000 Mar 14, 2010 12:01:00 AM GMT (Mar 13, 2010 6:01:00 PM CST) ok -> (Mar 14, 2010 12:01:00 AM GMT) Wrote: 1268524860000 Read: 1268524860000 Mar 14, 2010 1:01:00 AM GMT (Mar 13, 2010 7:01:00 PM CST) ok -> (Mar 14, 2010 1:01:00 AM GMT) Wrote: 1268528460000 Read: 1268528460000 Mar 14, 2010 2:01:00 AM GMT (Mar 13, 2010 8:01:00 PM CST) *FAILED -> (Mar 14, 2010 3:01:00 AM GMT) Wrote: 1268532060000 Read: 1268535660000 Difference: 3600000 Mar 14, 2010 3:01:00 AM GMT (Mar 13, 2010 9:01:00 PM CST) *FAILED -> (Mar 14, 2010 4:01:00 AM GMT) Wrote: 1268535660000 Read: 1268539260000 Difference: 3600000 Mar 14, 2010 4:01:00 AM GMT (Mar 13, 2010 10:01:00 PM CST) *FAILED -> (Mar 14, 2010 5:01:00 AM GMT) Wrote: 1268539260000 Read: 1268542860000 Difference: 3600000 Mar 14, 2010 5:01:00 AM GMT (Mar 13, 2010 11:01:00 PM CST) *FAILED -> (Mar 14, 2010 6:01:00 AM GMT) Wrote: 1268542860000 Read: 1268546460000 Difference: 3600000 Mar 14, 2010 6:01:00 AM GMT (Mar 14, 2010 12:01:00 AM CST) *FAILED -> (Mar 14, 2010 7:01:00 AM GMT) Wrote: 1268546460000 Read: 1268550060000 Difference: 3600000 Mar 14, 2010 7:01:00 AM GMT (Mar 14, 2010 1:01:00 AM CST) *FAILED -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268550060000 Read: 1268553660000 Difference: 3600000 Mar 14, 2010 8:01:00 AM GMT (Mar 14, 2010 3:01:00 AM CDT) ok -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268553660000 Read: 1268553660000 Mar 14, 2010 9:01:00 AM GMT (Mar 14, 2010 4:01:00 AM CDT) ok -> (Mar 14, 2010 9:01:00 AM GMT) Wrote: 1268557260000 Read: 1268557260000 Mar 14, 2010 10:01:00 AM GMT (Mar 14, 2010 5:01:00 AM CDT) ok -> (Mar 14, 2010 10:01:00 AM GMT) Wrote: 1268560860000 Read: 1268560860000 Dropping Table... Database Mode: EMBEDDED Local Time Zone: Central Standard Time Using Embedded Driver: org.apache.derby.jdbc.EmbeddedDriver Using Embedded URL: jdbc:derby:directory:C:\temp\dst_test_db;create=true Dropping Table... Creating Table... Mar 13, 2010 10:01:00 PM GMT (Mar 13, 2010 4:01:00 PM CST) ok -> (Mar 13, 2010 10:01:00 PM GMT) Wrote: 1268517660000 Read: 1268517660000 Mar 13, 2010 11:01:00 PM GMT (Mar 13, 2010 5:01:00 PM CST) ok -> (Mar 13, 2010 11:01:00 PM GMT) Wrote: 1268521260000 Read: 1268521260000 Mar 14, 2010 12:01:00 AM GMT (Mar 13, 2010 6:01:00 PM CST) ok -> (Mar 14, 2010 12:01:00 AM GMT) Wrote: 1268524860000 Read: 1268524860000 Mar 14, 2010 1:01:00 AM GMT (Mar 13, 2010 7:01:00 PM CST) ok -> (Mar 14, 2010 1:01:00 AM GMT) Wrote: 1268528460000 Read: 1268528460000 Mar 14, 2010 2:01:00 AM GMT (Mar 13, 2010 8:01:00 PM CST) ok -> (Mar 14, 2010 2:01:00 AM GMT) Wrote: 1268532060000 Read: 1268532060000 Mar 14, 2010 3:01:00 AM GMT (Mar 13, 2010 9:01:00 PM CST) ok -> (Mar 14, 2010 3:01:00 AM GMT) Wrote: 1268535660000 Read: 1268535660000 Mar 14, 2010 4:01:00 AM GMT (Mar 13, 2010 10:01:00 PM CST) ok -> (Mar 14, 2010 4:01:00 AM GMT) Wrote: 1268539260000 Read: 1268539260000 Mar 14, 2010 5:01:00 AM GMT (Mar 13, 2010 11:01:00 PM CST) ok -> (Mar 14, 2010 5:01:00 AM GMT) Wrote: 1268542860000 Read: 1268542860000 Mar 14, 2010 6:01:00 AM GMT (Mar 14, 2010 12:01:00 AM CST) ok -> (Mar 14, 2010 6:01:00 AM GMT) Wrote: 1268546460000 Read: 1268546460000 Mar 14, 2010 7:01:00 AM GMT (Mar 14, 2010 1:01:00 AM CST) ok -> (Mar 14, 2010 7:01:00 AM GMT) Wrote: 1268550060000 Read: 1268550060000 Mar 14, 2010 8:01:00 AM GMT (Mar 14, 2010 3:01:00 AM CDT) ok -> (Mar 14, 2010 8:01:00 AM GMT) Wrote: 1268553660000 Read: 1268553660000 Mar 14, 2010 9:01:00 AM GMT (Mar 14, 2010 4:01:00 AM CDT) ok -> (Mar 14, 2010 9:01:00 AM GMT) Wrote: 1268557260000 Read: 1268557260000 Mar 14, 2010 10:01:00 AM GMT (Mar 14, 2010 5:01:00 AM CDT) ok -> (Mar 14, 2010 10:01:00 AM GMT) Wrote: 1268560860000 Read: 1268560860000 Dropping Table...
          Hide
          Bryan Pendleton added a comment -

          Certain JDK implementations had out-of-date DST tables, with all the DST changes over the last few years.

          Have you verified that all of your JDK installations are fully patched?

          Show
          Bryan Pendleton added a comment - Certain JDK implementations had out-of-date DST tables, with all the DST changes over the last few years. Have you verified that all of your JDK installations are fully patched?
          Hide
          Keith Kruse added a comment -

          I believe so:

          C:\tzupdater-1.3.25-2009u>java -jar tzupdater.jar -u

          C:\tzupdater-1.3.25-2009u>java -jar tzupdater.jar -t -v
          java.home: C:\Program Files\Java\jre6
          java.vendor: Sun Microsystems Inc.
          java.version: 1.6.0_18
          JRE time zone data version: tzdata2009u
          Embedded time zone data version: tzdata2009u
          Validating the time zone data
          Validation complete

          === Starting Derby Server ===

          C:\db-derby-10.5.3\bin>java -version
          java version "1.6.0_18"
          Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
          Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)

          C:\db-derby-10.5.3\bin>startNetworkServer
          2010-03-15 16:49:22.094 GMT : Security manager installed using the Basic server security policy.
          2010-03-15 16:49:22.501 GMT : Apache Derby Network Server - 10.5.3.0 - (802917) started and ready to accept connections on port 1527

          === Logging Java Runtime in test class===

          I added this to my test class:

          log("Java Runtime Version: " + System.getProperty("java.runtime.version"));
          log("Java Path: " + System.getProperty("sun.boot.library.path"));

          and I get:

          Java Runtime Version: 1.6.0_18-b07
          Java Path: C:\Program Files\Java\jre6\bin

          Show
          Keith Kruse added a comment - I believe so: C:\tzupdater-1.3.25-2009u>java -jar tzupdater.jar -u C:\tzupdater-1.3.25-2009u>java -jar tzupdater.jar -t -v java.home: C:\Program Files\Java\jre6 java.vendor: Sun Microsystems Inc. java.version: 1.6.0_18 JRE time zone data version: tzdata2009u Embedded time zone data version: tzdata2009u Validating the time zone data Validation complete === Starting Derby Server === C:\db-derby-10.5.3\bin>java -version java version "1.6.0_18" Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing) C:\db-derby-10.5.3\bin>startNetworkServer 2010-03-15 16:49:22.094 GMT : Security manager installed using the Basic server security policy. 2010-03-15 16:49:22.501 GMT : Apache Derby Network Server - 10.5.3.0 - (802917) started and ready to accept connections on port 1527 === Logging Java Runtime in test class=== I added this to my test class: log("Java Runtime Version: " + System.getProperty("java.runtime.version")); log("Java Path: " + System.getProperty("sun.boot.library.path")); and I get: Java Runtime Version: 1.6.0_18-b07 Java Path: C:\Program Files\Java\jre6\bin
          Hide
          Knut Anders Hatlen added a comment -

          I see this too when I set the default timezone of my JVM to America/Chicago and run the test class. I also see the problem when I run with my local timezone (Central European time) and adjust the dates in the test to match the DST change in that timezone.

          If I keep the table populated by the client/server test and run the embedded test against it, I also see the problem in the embedded test, so it seems that embedded and client actually end up writing different dates to the database.

          If I do it the other way around, and run client/server tests against a table created by the embedded test, I still see the problem, but the number of discrepancies has been reduced from six to one. So it looks like we also have an issue with reading the values from the database.

          Show
          Knut Anders Hatlen added a comment - I see this too when I set the default timezone of my JVM to America/Chicago and run the test class. I also see the problem when I run with my local timezone (Central European time) and adjust the dates in the test to match the DST change in that timezone. If I keep the table populated by the client/server test and run the embedded test against it, I also see the problem in the embedded test, so it seems that embedded and client actually end up writing different dates to the database. If I do it the other way around, and run client/server tests against a table created by the embedded test, I still see the problem, but the number of discrepancies has been reduced from six to one. So it looks like we also have an issue with reading the values from the database.
          Hide
          Knut Anders Hatlen added a comment -

          I think I see what's going on now. The setTimestamp() method in the
          client driver, and its siblings setTime() and setDate(), use the
          supplied Calendar object to determine which timezone to convert the
          timestamp to before storing it. The way it does this, is by adjusting
          the timestamp by the same amount of time as the timezone difference
          between the supplied calendar and the default calendar.

          Although this adjustment will give the desired effect most of the
          time, it is broken because it actually changes the timestamp to point
          to a different point in time. Therefore it will miss on the exact time
          of the DST changes with a couple of hours and we see these
          discrepancies. We should only use the calendar to change the
          presentation of timestamp, not to change its value.

          I did the following experiment with the client code:

          1) removed the code that adjusts the timestamp value

          2) passed the calendar object down to the code that writes the
          timestamp to the network stream

          3) used the calendar object to extract the timezone-adjusted date
          and time out of the timezone

          Since in (3) we now have the unmodified timestamp value, there's no
          skew that confuses the conversion to the requested timezone, not even
          around time of the DST change.

          So with these changes, the correct values were sent from the client to
          the server. However, there was still one discrepancy between the
          values sent from the client and what's actually stored (this is an
          improvement, though, since there were six discrepancies without the
          change).

          This last discrepancy was caused by the handling of the timestamp on
          the server. The server does not use any Calendar object explicitly
          when parsing what it gets from the client or when storing the
          timestamp in the database. The default timezone will therefore be used
          in the handling of the timestamp. So when the client sends the
          timestamp 2010-03-14 02:01:00, which is a perfectly fine timestamp in
          the GMT timezone and many other timezones, the server (or more
          precisely, Timestamp.valueOf(String)) thinks the timestamp refers to a
          point in time within the "lost" hour in the America/Chicago timezone,
          and it silently adjusts it to 03:01:00 so that it's valid in that
          timezone too.

          Since we don't store the timezone together with the timestamp, it
          doesn't matter much which timezone the server uses when handling it,
          as long as it's consistent. However, since timezones that observe DST
          lose one hour when switching to DST, calendars using that timezone
          cannot reliably be used to represent times in other timezones. If the
          server instead had used a timezone that doesn't observe DST, like GMT,
          the timestamp wouldn't change on its way from the wire to the database
          even if the timestamp on the wire is not a valid time in the local
          timezone.

          With this in mind, I extended my experiment with the following changes
          in the server code (DRDAConnThread):

          4) when reading the (timezone-less) timestamp string sent from the
          client, put the values into a Calendar object with timezone set
          to GMT, and generate the timestamp from that Calendar

          5) use setTimestamp(int,Timestamp,Calendar) instead of
          setTimestamp(int,Timestamp) when passing the value to the
          embedded driver, with the Calendar's timezone set to GMT

          This took care of the last discrepancy and made the client/server
          setup store the exact same values on disk as the embedded setup did.

          However, there's still one error when reading the values back to the
          client, as noted in a previous comment about the incorrect reading of
          the values generated by the embedded test. I haven't investigated this
          problem yet, but I assume it's similar to the problems described
          above.

          Show
          Knut Anders Hatlen added a comment - I think I see what's going on now. The setTimestamp() method in the client driver, and its siblings setTime() and setDate(), use the supplied Calendar object to determine which timezone to convert the timestamp to before storing it. The way it does this, is by adjusting the timestamp by the same amount of time as the timezone difference between the supplied calendar and the default calendar. Although this adjustment will give the desired effect most of the time, it is broken because it actually changes the timestamp to point to a different point in time. Therefore it will miss on the exact time of the DST changes with a couple of hours and we see these discrepancies. We should only use the calendar to change the presentation of timestamp, not to change its value. I did the following experiment with the client code: 1) removed the code that adjusts the timestamp value 2) passed the calendar object down to the code that writes the timestamp to the network stream 3) used the calendar object to extract the timezone-adjusted date and time out of the timezone Since in (3) we now have the unmodified timestamp value, there's no skew that confuses the conversion to the requested timezone, not even around time of the DST change. So with these changes, the correct values were sent from the client to the server. However, there was still one discrepancy between the values sent from the client and what's actually stored (this is an improvement, though, since there were six discrepancies without the change). This last discrepancy was caused by the handling of the timestamp on the server. The server does not use any Calendar object explicitly when parsing what it gets from the client or when storing the timestamp in the database. The default timezone will therefore be used in the handling of the timestamp. So when the client sends the timestamp 2010-03-14 02:01:00, which is a perfectly fine timestamp in the GMT timezone and many other timezones, the server (or more precisely, Timestamp.valueOf(String)) thinks the timestamp refers to a point in time within the "lost" hour in the America/Chicago timezone, and it silently adjusts it to 03:01:00 so that it's valid in that timezone too. Since we don't store the timezone together with the timestamp, it doesn't matter much which timezone the server uses when handling it, as long as it's consistent. However, since timezones that observe DST lose one hour when switching to DST, calendars using that timezone cannot reliably be used to represent times in other timezones. If the server instead had used a timezone that doesn't observe DST, like GMT, the timestamp wouldn't change on its way from the wire to the database even if the timestamp on the wire is not a valid time in the local timezone. With this in mind, I extended my experiment with the following changes in the server code (DRDAConnThread): 4) when reading the (timezone-less) timestamp string sent from the client, put the values into a Calendar object with timezone set to GMT, and generate the timestamp from that Calendar 5) use setTimestamp(int,Timestamp,Calendar) instead of setTimestamp(int,Timestamp) when passing the value to the embedded driver, with the Calendar's timezone set to GMT This took care of the last discrepancy and made the client/server setup store the exact same values on disk as the embedded setup did. However, there's still one error when reading the values back to the client, as noted in a previous comment about the incorrect reading of the values generated by the embedded test. I haven't investigated this problem yet, but I assume it's similar to the problems described above.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a patch that shows the experiment I ran (calendar.diff) where we let the Calendar objects do the conversion to the correct timezone instead of using our own homegrown algorithm. The patch is not intended for commit.

          Show
          Knut Anders Hatlen added a comment - Attaching a patch that shows the experiment I ran (calendar.diff) where we let the Calendar objects do the conversion to the correct timezone instead of using our own homegrown algorithm. The patch is not intended for commit.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a patch with a JUnit regression test that exposes this bug. The test runs cleanly with the embedded driver and fails with the client driver. The patch also adds a new decorator that allows you to change the default timezone for a test suite (this decorator is used to force the test to use the America/Chicago timezone regardless of the local timezone).

          Show
          Knut Anders Hatlen added a comment - Attaching a patch with a JUnit regression test that exposes this bug. The test runs cleanly with the embedded driver and fails with the client driver. The patch also adds a new decorator that allows you to change the default timezone for a test suite (this decorator is used to force the test to use the America/Chicago timezone regardless of the local timezone).
          Hide
          Knut Anders Hatlen added a comment -

          Attaching an updated patch for the JUnit test case. In the new patch, we also test that we get the expected results when setTimestamp() is used to set a DATE or TIME parameter, and when getDate() or getTime() is used to fetch a TIMESTAMP column. The test still runs cleanly with the embedded driver and fails with the client driver.

          I have committed the updated test case to trunk with revision 932930, but it's not yet enabled in any test suite.

          Show
          Knut Anders Hatlen added a comment - Attaching an updated patch for the JUnit test case. In the new patch, we also test that we get the expected results when setTimestamp() is used to set a DATE or TIME parameter, and when getDate() or getTime() is used to fetch a TIMESTAMP column. The test still runs cleanly with the embedded driver and fails with the client driver. I have committed the updated test case to trunk with revision 932930, but it's not yet enabled in any test suite.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a new patch (upd-rs-test.diff) that makes DaylightSavingTest test yet another code path that's will be affected by the fix. The new test case uses an updatable result set to set the time values. The point of the test case is to verify that getDate/Time/Timestamp after updateDate/Time/Timestamp is able to do the timezone conversion correctly. The getters in the client result sets follow a different path to fetch the values from a separate data structure if the values have been updated locally.

          DaylightSavingTest is still not enabled in suites.All, as it only runs cleanly with the embedded driver.

          Committed revision 933637.

          I'll hold off posting a fix for this issue until the fix for DERBY-2602 has been committed, as these two issues touch many of the same methods.

          Show
          Knut Anders Hatlen added a comment - Attaching a new patch (upd-rs-test.diff) that makes DaylightSavingTest test yet another code path that's will be affected by the fix. The new test case uses an updatable result set to set the time values. The point of the test case is to verify that getDate/Time/Timestamp after updateDate/Time/Timestamp is able to do the timezone conversion correctly. The getters in the client result sets follow a different path to fetch the values from a separate data structure if the values have been updated locally. DaylightSavingTest is still not enabled in suites.All, as it only runs cleanly with the embedded driver. Committed revision 933637. I'll hold off posting a fix for this issue until the fix for DERBY-2602 has been committed, as these two issues touch many of the same methods.
          Hide
          Knut Anders Hatlen added a comment -

          The fix for DERBY-2602 went in yesterday, so it should be OK to start working on the fix for this issue. It looks to me as if there are four bugs in the timestamp handling (and some of these also apply to date and time) that need to be solved:

          1) The time skew issue that makes the client miss on the exact time of the DST switch when converting from local tz to GMT

          2) Timestamps that are not valid in the local timezone are silently changed when the server reads them from the client

          3) Timestamps that are not valid in the local timezone are silently changed when the server reads them from the database

          4) Timestamps that are not valid in the local timezone are silently changed when the client reads them from the server

          Fixing (1) will make the number of discrepancies in the original repro go down from six to one. But to get rid of the last discrepancy, we have to fix all of (2), (3) and (4).

          Show
          Knut Anders Hatlen added a comment - The fix for DERBY-2602 went in yesterday, so it should be OK to start working on the fix for this issue. It looks to me as if there are four bugs in the timestamp handling (and some of these also apply to date and time) that need to be solved: 1) The time skew issue that makes the client miss on the exact time of the DST switch when converting from local tz to GMT 2) Timestamps that are not valid in the local timezone are silently changed when the server reads them from the client 3) Timestamps that are not valid in the local timezone are silently changed when the server reads them from the database 4) Timestamps that are not valid in the local timezone are silently changed when the client reads them from the server Fixing (1) will make the number of discrepancies in the original repro go down from six to one. But to get rid of the last discrepancy, we have to fix all of (2), (3) and (4).
          Hide
          Knut Anders Hatlen added a comment -

          When I made some changes on the server to fix (3), I touched an area that was used to handle both CallableStatements and ResultSets. However, because of a bug (DERBY-4615) in the embedded implementation of CallableStatement.getTimestamp(int,Calendar) and friends, CallableStatements will only see half of the fix, and fixing the server code will therefore make the situation worse for CallableStatements until DERBY-4615. I think we should try to address DERBY-4615 before we attempt to fix (3), so that we don't introduce regressions for CallableStatements.

          Show
          Knut Anders Hatlen added a comment - When I made some changes on the server to fix (3), I touched an area that was used to handle both CallableStatements and ResultSets. However, because of a bug ( DERBY-4615 ) in the embedded implementation of CallableStatement.getTimestamp(int,Calendar) and friends, CallableStatements will only see half of the fix, and fixing the server code will therefore make the situation worse for CallableStatements until DERBY-4615 . I think we should try to address DERBY-4615 before we attempt to fix (3), so that we don't introduce regressions for CallableStatements.
          Hide
          Knut Anders Hatlen added a comment -

          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
          timezone.

          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
          calendar.

          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.

          Show
          Knut Anders Hatlen added a comment - 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 timezone. 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 calendar. 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.
          Hide
          Knut Anders Hatlen added a comment -

          I committed the 1a patch, revision 935868.

          Show
          Knut Anders Hatlen added a comment - I committed the 1a patch, revision 935868.
          Hide
          Knut Anders Hatlen added a comment -

          I went on to working on issue (2). I had to make the server use the timestamp methods that take a Calendar argument. However, that exposed the bug DERBY-4621, which made ParameterMappingTest fail. So it seems there's yet another bug that needs to be addressed before we can make the final changes to this one.

          Show
          Knut Anders Hatlen added a comment - I went on to working on issue (2). I had to make the server use the timestamp methods that take a Calendar argument. However, that exposed the bug DERBY-4621 , which made ParameterMappingTest fail. So it seems there's yet another bug that needs to be addressed before we can make the final changes to this one.
          Hide
          Knut Anders Hatlen added a comment -

          Attached is a patch that addresses issue (2), when the server is receiving timestamps (or dates or times) from the client. The patch makes the server use the GMT timezone instead of the local timezone when it parses the timestamps, so that there are no holes in the range of valid values. With this patch, the repro still has one failure (because of issue 3 and 4), but now all the values are stored correctly in the database.

          When running the regression tests, ParameterMappingTest fails because the new code path in the server triggers DERBY-4621. The 2a patch should therefore not be committed before DERBY-4621 has been solved. I'm still attaching the patch here and setting the patch available flag.

          Show
          Knut Anders Hatlen added a comment - Attached is a patch that addresses issue (2), when the server is receiving timestamps (or dates or times) from the client. The patch makes the server use the GMT timezone instead of the local timezone when it parses the timestamps, so that there are no holes in the range of valid values. With this patch, the repro still has one failure (because of issue 3 and 4), but now all the values are stored correctly in the database. When running the regression tests, ParameterMappingTest fails because the new code path in the server triggers DERBY-4621 . The 2a patch should therefore not be committed before DERBY-4621 has been solved. I'm still attaching the patch here and setting the patch available flag.
          Hide
          Knut Anders Hatlen added a comment -

          Committed the 2a patch, revision 936218.

          Show
          Knut Anders Hatlen added a comment - Committed the 2a patch, revision 936218.
          Hide
          Knut Anders Hatlen added a comment -

          The attached patch derby-4582-3a-server-send.diff modifies DRDAConnThread to address issue (3). It makes the server use a GMT calendar when reading TIME, DATE or TIMESTAMP values out of the database, and uses the same GMT calendar to format the string representation that it sends to the client. This way, the value read from the database is not silently changed if it happens to represent a time that is not valid in the local time zone.

          With this patch, the values are sent correctly from the client, stored correctly in the database and sent correctly back to the client. However, because of issue (4), there's still one value that's returned one hour off at the client.

          All the regression tests ran cleanly with this patch.

          Show
          Knut Anders Hatlen added a comment - The attached patch derby-4582-3a-server-send.diff modifies DRDAConnThread to address issue (3). It makes the server use a GMT calendar when reading TIME, DATE or TIMESTAMP values out of the database, and uses the same GMT calendar to format the string representation that it sends to the client. This way, the value read from the database is not silently changed if it happens to represent a time that is not valid in the local time zone. With this patch, the values are sent correctly from the client, stored correctly in the database and sent correctly back to the client. However, because of issue (4), there's still one value that's returned one hour off at the client. All the regression tests ran cleanly with this patch.
          Hide
          Knut Anders Hatlen added a comment -

          Committed the 3a patch with revision 937170.

          Show
          Knut Anders Hatlen added a comment - Committed the 3a patch with revision 937170.
          Hide
          Knut Anders Hatlen added a comment -

          Here's a patch to address issue (4), derby-4582-4a-client-receive.diff.

          The patch makes the client driver use the specified calendar object
          when parsing the values received from the server. With this patch, the
          original repro runs cleanly, and so does all the test cases in
          DaylightSavingTest. I am currently running the rest of the regression
          tests.

          More details about the changes:

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

          • Changed some method signatures to allow passing Calendar objects
            further down.
          • Made date_valueOf(), time_valueOf() and timestamp_valueOf() use a
            calendar when parsing the strings

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

          • Made the getters take a calendar and pass it to the parsing methods
            in am.DateTime instead of passing an instance of the default
            calendar

          M java/client/org/apache/derby/client/am/ResultSet.java
          M java/client/org/apache/derby/client/am/CallableStatement.java

          • Passed the calendar from getDate, getTime, getTimestamp to the
            getters in am.Cursor

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/_Suite.java

          • Enabled DaylightSavingTest as part of suites.All
          Show
          Knut Anders Hatlen added a comment - Here's a patch to address issue (4), derby-4582-4a-client-receive.diff. The patch makes the client driver use the specified calendar object when parsing the values received from the server. With this patch, the original repro runs cleanly, and so does all the test cases in DaylightSavingTest. I am currently running the rest of the regression tests. More details about the changes: M java/client/org/apache/derby/client/am/CrossConverters.java Changed some method signatures to allow passing Calendar objects further down. Made date_valueOf(), time_valueOf() and timestamp_valueOf() use a calendar when parsing the strings M java/client/org/apache/derby/client/am/Cursor.java Made the getters take a calendar and pass it to the parsing methods in am.DateTime instead of passing an instance of the default calendar M java/client/org/apache/derby/client/am/ResultSet.java M java/client/org/apache/derby/client/am/CallableStatement.java Passed the calendar from getDate, getTime, getTimestamp to the getters in am.Cursor M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/_Suite.java Enabled DaylightSavingTest as part of suites.All
          Hide
          Knut Anders Hatlen added a comment -

          All the regression tests ran cleanly with the 4a patch.

          Show
          Knut Anders Hatlen added a comment - All the regression tests ran cleanly with the 4a patch.
          Hide
          Knut Anders Hatlen added a comment -

          Committed 4a to trunk with revision 938547.

          All the patches up to 3a were committed before the 10.6 branch was created and are included in the 10.6.1.0 release candidate. The 4a patch is not on the 10.6 branch yet, but I intend to back-port it in a couple of days if the nightly regression tests don't show any problems.

          I think there still are some outstanding issues. I'll file separate JIRAs for those so that we can resolve this one.

          Show
          Knut Anders Hatlen added a comment - Committed 4a to trunk with revision 938547. All the patches up to 3a were committed before the 10.6 branch was created and are included in the 10.6.1.0 release candidate. The 4a patch is not on the 10.6 branch yet, but I intend to back-port it in a couple of days if the nightly regression tests don't show any problems. I think there still are some outstanding issues. I'll file separate JIRAs for those so that we can resolve this one.
          Hide
          Knut Anders Hatlen added a comment -

          Some of the code added in the 4a patch wasn't exercised by any of the existing tests, so of course it contained a bug. I noticed that DaylightSavingTest failed if I changed it to insert the values into VARCHAR columns instead of TIMESTAMP, TIME and DATE. The problem was with the method in CrossConverters that parses the date portion of a DATE or a TIMESTAMP when converting from a VARCHAR value. It didn't take into account that java.util.Calendar counts months from 0.

          The attached patch adds test cases that test conversion between VARCHAR and date/time values in DaylightSavingTest, and fixes the off-by-one-month bug.

          Running the rest of the regression tests now.

          Show
          Knut Anders Hatlen added a comment - Some of the code added in the 4a patch wasn't exercised by any of the existing tests, so of course it contained a bug. I noticed that DaylightSavingTest failed if I changed it to insert the values into VARCHAR columns instead of TIMESTAMP, TIME and DATE. The problem was with the method in CrossConverters that parses the date portion of a DATE or a TIMESTAMP when converting from a VARCHAR value. It didn't take into account that java.util.Calendar counts months from 0. The attached patch adds test cases that test conversion between VARCHAR and date/time values in DaylightSavingTest, and fixes the off-by-one-month bug. Running the rest of the regression tests now.
          Hide
          Knut Anders Hatlen added a comment -

          All tests passed. Committed patch 5a with revision 938796.

          Show
          Knut Anders Hatlen added a comment - All tests passed. Committed patch 5a with revision 938796.
          Hide
          Knut Anders Hatlen added a comment -

          The JUnit test case fails on the small device platforms because it uses some java.util.Date methods that are not part of the Foundation Profile 1.1 API. The attached patch (derby-4582-6a-javame.diff) makes the test use java.util.Calendar to extract fields from dates instead of the unsupported methods.

          Committed revision 939231.

          Show
          Knut Anders Hatlen added a comment - The JUnit test case fails on the small device platforms because it uses some java.util.Date methods that are not part of the Foundation Profile 1.1 API. The attached patch (derby-4582-6a-javame.diff) makes the test use java.util.Calendar to extract fields from dates instead of the unsupported methods. Committed revision 939231.
          Hide
          Knut Anders Hatlen added a comment -

          Merged the last three fixes to 10.6 and committed revision 940460.
          Marking as resolved.

          Show
          Knut Anders Hatlen added a comment - Merged the last three fixes to 10.6 and committed revision 940460. Marking as resolved.
          Hide
          Kathey Marsden added a comment -

          reopen for 10.5 back port

          Show
          Kathey Marsden added a comment - reopen for 10.5 back port
          Hide
          Mamta A. Satoor added a comment -

          Will work on backporting it to 10.5

          Show
          Mamta A. Satoor added a comment - Will work on backporting it to 10.5
          Hide
          Mamta A. Satoor added a comment -

          Sorry, didn't notice that Lily had already assigned this jira to herself for backporting. I have taken my name off of this jira.

          Show
          Mamta A. Satoor added a comment - Sorry, didn't notice that Lily had already assigned this jira to herself for backporting. I have taken my name off of this jira.
          Hide
          Lily Wei added a comment -

          Don't worry about it, Mamta. Yes, I will back port this to 10.5.

          Show
          Lily Wei added a comment - Don't worry about it, Mamta. Yes, I will back port this to 10.5.
          Hide
          Lily Wei added a comment -

          Wow! Porting to 10.5 for this issue is a little bit hairy. From reading all the comments, I figure I might only need to port changelist 940460.
          After executing 'svn merge -c940460 https://svn.apache.org/repos/asf/db/derby/code/branches/10.6/', I was able to compile 10.5 branch. Yeah! However, running DaylightSavingTest failed with the following message:
          1) testConversionToGMTAroundDSTChange(org.apache.derbyTesting.functionTests.test
          s.jdbcapi.DaylightSavingTest)junit.framework.AssertionFailedError: TS expected:<
          2010-03-13 20:01:00.0> but was:<2010-03-13 21:01:00.0>
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.DaylightSavingTes
          t.testConversionToGMTAroundDSTChange(DaylightSavingTest.java:129)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

          I am thinking I will port more changes to try to fix this issue.
          I port changelist 936218 and 937170 with comment 'svn merge -c936218 https://svn.apache.org/repos/asf/db/derby/code/trunk/' and 'svn merge -c937170 https://svn.apache.org/repos/asf/db/derby/code/trunk/'. DaylightSavingTest is still giving me the same failure information and I am able to compile 10.5 branch. I am attaching the diff I have at this point with derby-4582-10.5.diff

          Due to the fact DaylightSavingTest is still failing, I then port changelist 935869. I was not able to compile 10.5 branch at this point.
          Compile failed at:
          compile:
          [javac] Compiling 141 source files to c:\derby\10.5\classes
          [javac] c:\derby\10.5\java\client\org\apache\derby\client\net\Request.java:1
          559: timestampToTimestampBytes(byte[],int,org.apache.derby.client.am.DateTimeVal
          ue,boolean) in org.apache.derby.client.am.DateTime cannot be applied to (byte[],
          int,org.apache.derby.client.am.DateTimeValue)
          [javac] org.apache.derby.client.am.DateTime.timestampToTimestamp
          Bytes(bytes_, offset_, timestamp);
          [javac] ^
          I notice my merge for Request.java at java/client/org/apache/derby/client/net/ is very different than the diff in JIRI DERBY-4582 http://svn.apache.org/viewvc/db/derby/code/trunk/java/client/org/apache/derby/client/net/Request.java?p2=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fclient%2Forg%2Fapache%2Fderby%2Fclient%2Fnet%2FRequest.java&p1=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fclient%2Forg%2Fapache%2Fderby%2Fclient%2Fnet%2FRequest.java&r1=935868&r2=935867&view=diff&pathrev=935868
          At line 1553, I have diff as following:

          • final void writeTimestamp(java.sql.Timestamp timestamp) throws SqlException
            {
            + final void writeTimestamp(DateTimeValue timestamp) throws SqlException {
            try{
            ensureLength(offset_ + 26);
            org.apache.derby.client.am.DateTime.timestampToTimestampBytes(bytes
            , offset, timestamp);

          I can try to manually change this. However, I have a feeling I might need to change Connection.java in order to have method serverSupportsTimestampNanoseconds

          Should I keep trying to port this issue to 10.5 branch? Any suggestion is welcome.

          Show
          Lily Wei added a comment - Wow! Porting to 10.5 for this issue is a little bit hairy. From reading all the comments, I figure I might only need to port changelist 940460. After executing 'svn merge -c940460 https://svn.apache.org/repos/asf/db/derby/code/branches/10.6/ ', I was able to compile 10.5 branch. Yeah! However, running DaylightSavingTest failed with the following message: 1) testConversionToGMTAroundDSTChange(org.apache.derbyTesting.functionTests.test s.jdbcapi.DaylightSavingTest)junit.framework.AssertionFailedError: TS expected:< 2010-03-13 20:01:00.0> but was:<2010-03-13 21:01:00.0> at org.apache.derbyTesting.functionTests.tests.jdbcapi.DaylightSavingTes t.testConversionToGMTAroundDSTChange(DaylightSavingTest.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) I am thinking I will port more changes to try to fix this issue. I port changelist 936218 and 937170 with comment 'svn merge -c936218 https://svn.apache.org/repos/asf/db/derby/code/trunk/ ' and 'svn merge -c937170 https://svn.apache.org/repos/asf/db/derby/code/trunk/ '. DaylightSavingTest is still giving me the same failure information and I am able to compile 10.5 branch. I am attaching the diff I have at this point with derby-4582-10.5.diff Due to the fact DaylightSavingTest is still failing, I then port changelist 935869. I was not able to compile 10.5 branch at this point. Compile failed at: compile: [javac] Compiling 141 source files to c:\derby\10.5\classes [javac] c:\derby\10.5\java\client\org\apache\derby\client\net\Request.java:1 559: timestampToTimestampBytes(byte[],int,org.apache.derby.client.am.DateTimeVal ue,boolean) in org.apache.derby.client.am.DateTime cannot be applied to (byte[], int,org.apache.derby.client.am.DateTimeValue) [javac] org.apache.derby.client.am.DateTime.timestampToTimestamp Bytes(bytes_, offset_, timestamp); [javac] ^ I notice my merge for Request.java at java/client/org/apache/derby/client/net/ is very different than the diff in JIRI DERBY-4582 http://svn.apache.org/viewvc/db/derby/code/trunk/java/client/org/apache/derby/client/net/Request.java?p2=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fclient%2Forg%2Fapache%2Fderby%2Fclient%2Fnet%2FRequest.java&p1=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fclient%2Forg%2Fapache%2Fderby%2Fclient%2Fnet%2FRequest.java&r1=935868&r2=935867&view=diff&pathrev=935868 At line 1553, I have diff as following: final void writeTimestamp(java.sql.Timestamp timestamp) throws SqlException { + final void writeTimestamp(DateTimeValue timestamp) throws SqlException { try{ ensureLength(offset_ + 26); org.apache.derby.client.am.DateTime.timestampToTimestampBytes(bytes , offset , timestamp); I can try to manually change this. However, I have a feeling I might need to change Connection.java in order to have method serverSupportsTimestampNanoseconds Should I keep trying to port this issue to 10.5 branch? Any suggestion is welcome.
          Hide
          Lily Wei added a comment -

          I tried to use changelist 932930, 933637, 933726, 935868, 936218, 937170, 94046. changelist 933726 is a check-in for DERBY-2602 allows full JDBC nanosecond-precision in timestamps across the network. However, I am still having build problem and DaylightSavingTest still behave with DERBY-4582.
          If there is no objection, I would recommend not back port to 10.5 branches for this issue.

          Show
          Lily Wei added a comment - I tried to use changelist 932930, 933637, 933726, 935868, 936218, 937170, 94046. changelist 933726 is a check-in for DERBY-2602 allows full JDBC nanosecond-precision in timestamps across the network. However, I am still having build problem and DaylightSavingTest still behave with DERBY-4582 . If there is no objection, I would recommend not back port to 10.5 branches for this issue.
          Hide
          Kathey Marsden added a comment -

          I think that is fine Lily. It doesn't sound like it is worth the effort for now. Someday if someone really needs this fix they can work on the back port.

          Show
          Kathey Marsden added a comment - I think that is fine Lily. It doesn't sound like it is worth the effort for now. Someday if someone really needs this fix they can work on the back port.
          Hide
          Lily Wei added a comment -

          This sounds great to me. Thank you so much, Kathey.

          Show
          Lily Wei added a comment - This sounds great to me. Thank you so much, Kathey.
          Hide
          Lily Wei added a comment -

          This issue is not going to back port to 10.5. Reassign back to Knut.

          Show
          Lily Wei added a comment - This issue is not going to back port to 10.5. Reassign back to Knut.
          Hide
          Lily Wei added a comment -

          Change resolution back to fixed.

          Show
          Lily Wei added a comment - Change resolution back to fixed.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Keith Kruse
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development