[
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
