Uploaded image for project: '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

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

      Attachments

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

        Issue Links

          Activity

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

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

            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?

            bryanpendleton 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?
            keith13660 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

            keith13660 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

            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.

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

            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.

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

            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.

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

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

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

            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.

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

            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.

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

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

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

            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.

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

            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.

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

            I committed the 1a patch, revision 935868.

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

            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.

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

            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.

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

            Committed the 2a patch, revision 936218.

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

            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.

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

            Committed the 3a patch with revision 937170.

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

            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
            knutanders 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

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

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

            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.

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

            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.

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

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

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

            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.

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

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

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

            reopen for 10.5 back port

            kmarsden Katherine Marsden added a comment - reopen for 10.5 back port

            Will work on backporting it to 10.5

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

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

            mamtas 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.
            lilywei Lily Wei added a comment -

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

            lilywei Lily Wei added a comment - Don't worry about it, Mamta. Yes, I will back port this to 10.5.
            lilywei 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.

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

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

            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.

            kmarsden Katherine 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.
            lilywei Lily Wei added a comment -

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

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

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

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

            Change resolution back to fixed.

            lilywei Lily Wei added a comment - Change resolution back to fixed.

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

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

            People

              knutanders Knut Anders Hatlen
              keith13660 Keith Kruse
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: