You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Keith Kruse (JIRA)" <ji...@apache.org> on 2010/03/15 16:14:27 UTC
[jira] Created: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
-------------------------------------------------------------------------------------------------------------------
Key: DERBY-4582
URL: https://issues.apache.org/jira/browse/DERBY-4582
Project: Derby
Issue Type: Bug
Affects Versions: 10.5.3.0
Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
Reporter: Keith Kruse
This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
I have a complete test class I can attach, but here is a summary:
private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
...
String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
String sql2 = "SELECT * from app.dst_test where id=?";
...
ps.setTimestamp(2, ts, gmtCal);
...
Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888203#action_12888203 ]
Lily Wei commented on DERBY-4582:
---------------------------------
Don't worry about it, Mamta. Yes, I will back port this to 10.5.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845392#action_12845392 ]
Bryan Pendleton commented on DERBY-4582:
----------------------------------------
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?
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857249#action_12857249 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858882#action_12858882 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Keith Kruse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845406#action_12845406 ]
Keith Kruse commented on DERBY-4582:
------------------------------------
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
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lily Wei reassigned DERBY-4582:
-------------------------------
Assignee: Knut Anders Hatlen (was: Lily Wei)
This issue is not going to back port to 10.5. Reassign back to Knut.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reassigned DERBY-4582:
-----------------------------------------
Assignee: Knut Anders Hatlen
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-5a-bugfix.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Issue & fix info: (was: [Patch Available])
Committed the 2a patch, revision 936218.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-1a-client-send.diff
Attached is a patch (derby-4582-1a-client-send.diff) that addresses
issue (1) described above. That is, sending of date, time and
timestamp from the client.
It makes the following changes:
A java/client/org/apache/derby/client/am/DateTimeValue.java
New class that represents a Time, Date or Timestamp in a specified
calendar. This class preserves the representation of the time in the
specified calendar so that it's not affected by oddities in the local
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Component/s: Network Client
Issue & fix info: (was: [Newcomer])
Bug behavior facts: [Embedded/Client difference, Wrong query result] (was: [Wrong query result])
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860156#action_12860156 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
Committed the 3a patch with revision 937170.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: upd-rs-test.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888168#action_12888168 ]
Mamta A. Satoor commented on DERBY-4582:
----------------------------------------
Will work on backporting it to 10.5
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Mamta A. Satoor
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-4582.
---------------------------------------
Fix Version/s: 10.6.1.1
Resolution: Fixed
Merged the last three fixes to 10.6 and committed revision 940460.
Marking as resolved.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861689#action_12861689 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
All tests passed. Committed patch 5a with revision 938796.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856901#action_12856901 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
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).
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Issue & fix info: (was: [Patch Available])
I committed the 1a patch, revision 935868.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854404#action_12854404 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reopened DERBY-4582:
-----------------------------------
reopen for 10.5 back port
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-6a-javame.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: calendar.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor reassigned DERBY-4582:
--------------------------------------
Assignee: Lily Wei (was: Mamta A. Satoor)
Sorry, didn't notice that Lily had already assigned this jira to herself for backporting. I have taken my name off of this jira.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: junit.diff
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).
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java, junit.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Issue & fix info: [Patch Available]
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Fix Version/s: 10.7.0.0
Issue & fix info: (was: [Patch Available])
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-3a-server-send.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lily Wei resolved DERBY-4582.
-----------------------------
Resolution: Fixed
Change resolution back to fixed.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lily Wei updated DERBY-4582:
----------------------------
Attachment: derby-4582-10.5.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Keith Kruse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Kruse updated DERBY-4582:
-------------------------------
Attachment: DerbyTest.java
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...
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Issue & fix info: [Patch Available]
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-2a-server-receive.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Issue & fix info: [Patch Available]
All the regression tests ran cleanly with the 4a patch.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lily Wei reassigned DERBY-4582:
-------------------------------
Assignee: Lily Wei (was: Knut Anders Hatlen)
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889913#action_12889913 ]
Kathey Marsden commented on DERBY-4582:
---------------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889942#action_12889942 ]
Lily Wei commented on DERBY-4582:
---------------------------------
This sounds great to me. Thank you so much, Kathey.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: junit.diff
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, DerbyTest.java, junit.diff, junit.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor reassigned DERBY-4582:
--------------------------------------
Assignee: Mamta A. Satoor (was: Lily Wei)
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Mamta A. Satoor
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Lily Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889890#action_12889890 ]
Lily Wei commented on DERBY-4582:
---------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Lily Wei
> Fix For: 10.6.1.1, 10.7.0.0
>
> Attachments: calendar.diff, derby-4582-10.5.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, derby-4582-5a-bugfix.diff, derby-4582-6a-javame.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4582) Timestamps inserted with GMT
calendar are 1 hour later when subsequently read with GMT calendar (Server
Mode Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854866#action_12854866 ]
Knut Anders Hatlen commented on DERBY-4582:
-------------------------------------------
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.
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: DerbyTest.java
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4582) Timestamps inserted with GMT calendar
are 1 hour later when subsequently read with GMT calendar (Server Mode
Only).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4582:
--------------------------------------
Attachment: derby-4582-4a-client-receive.diff
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
> Timestamps inserted with GMT calendar are 1 hour later when subsequently read with GMT calendar (Server Mode Only).
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4582
> URL: https://issues.apache.org/jira/browse/DERBY-4582
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.3.0
> Environment: Windows XP Professional Version 2002 Service Pack 3, Central Standard Time Zone (America/Chicago)
> Reporter: Keith Kruse
> Assignee: Knut Anders Hatlen
> Attachments: calendar.diff, derby-4582-1a-client-send.diff, derby-4582-2a-server-receive.diff, derby-4582-3a-server-send.diff, derby-4582-4a-client-receive.diff, DerbyTest.java, junit.diff, junit.diff, upd-rs-test.diff
>
>
> This issue only appears to happen in Network Server/Client mode. Embedded mode does not have the issue.
> My timezone is American/Chicago. Saving timestamps with values for the 6 hours prior to DST start are being read back in as values 1 hour later than written. (I believe the issue happens on the write because values written in Network Server/Client mode and read in Embedded mode are incorrect, while values written and read in Embedded mode are corect.)
> Values between 3/13/2010 - 20:00 CST and 3/14/2010 - 02:00 CST will return timstamps 1 hour off. The "setTimestamp" method is being passed a GMT calendar with the timestamp:
> I have a complete test class I can attach, but here is a summary:
> private final TimeZone gmtTZ = TimeZone.getTimeZone("GMT");
> private final Calendar gmtCal = Calendar.getInstance(gmtTZ);
> ...
> String sql = "INSERT INTO app.dst_test (id, gmt_timestamp, milli_time) VALUES(?,?,?)";
> String sql2 = "SELECT * from app.dst_test where id=?";
> ...
> ps.setTimestamp(2, ts, gmtCal);
> ...
> Timestamp tsRead = rs.getTimestamp("gmt_timestamp", gmtCal);
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.