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 "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/09/06 15:31:22 UTC
[jira] Created: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
-----------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-1816
URL: http://issues.apache.org/jira/browse/DERBY-1816
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.2.1.0, 10.3.0.0
Reporter: Daniel John Debrunner
Priority: Minor
In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
In client the millisecond time value for such a value is always set to zero.
Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
it should retain the precision.
The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
with a comment with this bug number.
private void assertTimeEqual(Time tv, Timestamp tsv)
{
cal.clear();
cal.setTime(tv);
int hour = cal.get(Calendar.HOUR_OF_DAY);
int min = cal.get(Calendar.MINUTE);
int sec = cal.get(Calendar.SECOND);
int ms = cal.get(Calendar.MILLISECOND);
// Check the time portion is set to the same as tv
cal.clear();
cal.setTime(tsv);
assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
assertEquals(min, cal.get(Calendar.MINUTE));
assertEquals(sec, cal.get(Calendar.SECOND));
assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494841 ]
A B commented on DERBY-1816:
----------------------------
Right, but embedded is also working on an instance of SQLTimestamp, which already has a notion of "time" from which it can pull the right pieces. So it's easier there.
In client all we have a is a string. We have to parse that string into *something* that can be translated into hours, minutes, seconds, etc.
> it should be possible for the client to do the same.
Yes, it is possible, I didn't mean to suggest it wasn't. We do that today. But in order to fix this Jira we'd have to explicitly parse the various pieces out of the string, just as we do with getTimestamp(). So we either duplicate the timestamp parsing code (ick), or we do something like:
int [] tsFields = new int [7];
parseTimestampString(timestamp, tsFields);
cal.set(tsFields[0], tsFields[1], ...)
Either way is possible, it's just that neither is particular pretty. But if instantiating an extra Timestamp is so bad, it would of course be worth it.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494122 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
The javadoc for the getTimestamp() with a calendar object state that the passed in Calendar is the one to use in creating the java.sql.Timestamp object.
"This method uses the given calendar to construct an appropriate millisecond value for the timestamp if the underlying database does not store timezone information."
"cal - the java.util.Calendar object to use in constructing the date"
So I think the embedded behaviour is within the spec. In fact one might be able to read the spec in such a way that it is expected the passed in Calendar
object is modified by the call and set to the value corresponding to the column, thus maybe client behaviour is incorrect?
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493824 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
> Note that for getXXX() methods which *do* take a Calendar object, the client code first calls the version of the method that takes no arguments (which is what the cleanup_v1 patch affects) and then normalizes the result based on the timezone of the received Calendar object.
any idea why they don't just use the calendar passed in and just perform the conversion once? I think that's what embedded does.
Ie. the no calendar version calls the calendar version with a default calendar.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B reassigned DERBY-1816:
--------------------------
Assignee: A B
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B resolved DERBY-1816.
------------------------
Resolution: Fixed
Fix Version/s: 10.3.0.0
Thanks for the review, Bryan! I re-ran suites.All and derbyall on SUSE Linux with ibm142 and everything ran cleanly with _v1 patch as attached to this issue. So I committed with svn # 541333:
URL: http://svn.apache.org/viewvc?view=rev&rev=541333
I also filed DERBY-2690 for tracking of Dan's comments/suggestion re: the current problems with the client's implementation of getTimestamp() with a Calendar object.
Marking the issue as resolved for 10.3.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494319 ]
A B commented on DERBY-1816:
----------------------------
> Unless I hear objections pretty quickly, I'll plan to commit the cleanup_v1 patch later this morning.
Actually, I'm not sure how much time I'll have over the next few days to work with this particular issue. I may need to revisit my approach in light of Dan's comments. So I'll hold off committing for now.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494101 ]
A B commented on DERBY-1816:
----------------------------
> any idea why they don't just use the calendar passed in and just perform the conversion once?
> I think that's what embedded does.
I looked at the differences between embedded and client and while I'm not sure what the answer to your question is (i.e. why client doesn't "just use the calendar passed in") I did notice a difference in behavior that struck me as noteworthy.
Namely, when a call to a getXXX() date/time method is made and a Calendar object is passed in, embedded will clobber (or at least wipe out) the received Calendar argument's value. With the client, though, the argument is preserved (which is more what I would have expected).
So while I can look into making the client mimic the embedded behavior, I'm not sure that this particular piece of behavior (clobbering the Calendar argument's value) is correct.
Ex: If "rs" is a ResultSet whose first column is the TIMESTAMP value "2007-05-03 16:49:52.883" then a call to the "assertGetWithCal()" method below will return something similar to the following:
On embedded:
targetBefore -=> 9 10, 2010 -- 10:10:10.205 (GMT-10:00)
got cal -=> 4 3, 2007 -- 19:49:52.883 (America/Los_Angeles)
targetAfter -=> 4 3, 2007 -- 16:49:52.0 (GMT-10:00)
With client:
targetBefore -=> 9 10, 2010 -- 10:10:10.607 (GMT-10:00)
got cal -=> 4 3, 2007 -- 19:49:52.883 (America/Los_Angeles)
targetAfter -=> 9 10, 2010 -- 10:10:10.607 (GMT-10:00)
Notice how, with embedded, "targetAfter" has the same year, month, day, and time as the result of the "getTimestamp(Calendar)" call, and also that the millisecond value has been wiped out. But with client, "targetAfter" matches "targetBefore". In both cases the correct timezone adjustment takes place.
My guess is that the embedded behavior is incorrect, but I'm not confident enough to say for sure.
Any other opinions?
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494140 ]
A B commented on DERBY-1816:
----------------------------
> So I think the embedded behaviour is within the spec. In fact one might be able to read the
> spec in such a way that it is expected the passed in Calendar object is modified by the call
> and set to the value corresponding to the column, thus maybe client behaviour is incorrect?
Hmm. So we are to read "object to use in constructing the date" as "object in which to return the constructed date"?
Seems odd to a) return the timestamp value as a java.sql.Timestamp, *and* b) return the timestamp via the received Calendar object.
If that is in fact the correct behavior, then is there a bug in embedded because it truncates the milliseconds? I.e.:
On embedded:
targetBefore -=> 9 10, 2010 -- 10:10:10.205 (GMT-10:00)
got cal -=> 4 3, 2007 -- 19:49:52.883 (America/Los_Angeles)
targetAfter -=> 4 3, 2007 -- 16:49:52.0 (GMT-10:00)
Note how the "targetAfter" object has no milliseconds.
For what it's worth, I ran the exact same program against a DB2 database and, as with Derby client, the Calendar object is *not* modified. I don't have any other RDMBs against which to try...
In any event, I think this discussion goes beyond the scope of the "recyclableCleanup_v1.patch", which is targeted for a very specific type of cleanup--and one that does not itself alter functionality. Maybe changes to way in which client handles Calendar objects can be filed as a separate issue?
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494302 ]
A B commented on DERBY-1816:
----------------------------
Thank you for your extensive comments on this, Dan!
> Looking at the network client's implementation of getTimeStamp() with a Calendar I have to
> say it seems inefficient, confusing
I definitely agree with you here!
> and wrong. :-)
Well...okay. Do you by chance know of a concrete repro to demonstrate what you have described above?
> What is required is the same approach as embedded, which is to always perform
> YYYY-MM-DD:hh:mm:ss.ffff >> Calendar >> long milli-seconds >> java.sql.Timestamp
Sounds like a separate Jira, agreed?
Is it okay to proceed with committing the recyclableCleanup_v1.patch (and subquent fix) for this issue as it is now? I don't think my changes make the situation any worse, and they will make it easier to resolve this issue--and also DERBY-889, I believe.
Unless I hear objections pretty quickly, I'll plan to commit the cleanup_v1 patch later this morning.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494881 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
or just pass in a calendar object into the parse method, e.g. re-write timestampBytesToTimestamp() to pass in a calendar and then create the java.sql.Timestamp object outside when required.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494102 ]
A B commented on DERBY-1816:
----------------------------
"assertGetWithCal()" as referenced in previous comment (forgot to paste):
----
private void assertGetWithCal(ResultSet rs) throws Exception
{
Calendar targetCal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT-10:00"));
targetCal.set(2010, Calendar.OCTOBER, 10, 10, 10, 10);
System.out.println(" targetBefore -=> " + printCalendar(targetCal));
Timestamp tsv = rs.getTimestamp(1, targetCal);
Calendar getCal = Calendar.getInstance();
getCal.setTime(tsv);
// System.out.println(" got ts -=> " + tsv + " (" + tsv.getTimezoneOffset() + ")");
System.out.println(" got cal -=> " + printCalendar(getCal));
System.out.println(" targetAfter -=> " + printCalendar(targetCal) + "\n");
return;
}
private String printCalendar(Calendar cal)
{
StringBuffer sbuf = new StringBuffer();
sbuf.append(cal.get(Calendar.MONTH) + " ");
sbuf.append(cal.get(Calendar.DAY_OF_MONTH) + ", ");
sbuf.append(cal.get(Calendar.YEAR) + " -- ");
sbuf.append(cal.get(Calendar.HOUR_OF_DAY) + ":");
sbuf.append(cal.get(Calendar.MINUTE) + ":");
sbuf.append(cal.get(Calendar.SECOND) + ".");
sbuf.append(cal.get(Calendar.MILLISECOND));
sbuf.append(" (" + cal.getTimeZone().getID() + ")");
return sbuf.toString();
}
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494170 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
AB> Seems odd to a) return the timestamp value as a java.sql.Timestamp, *and* b) return the timestamp via the received Calendar object.
What's the alternative semantics? Ie. given a Calendar object and the SQL representation of a TIMESTAMP, how does a JDBC driver
use the passed in Calendar object to create a valid JDBC java.sql.Timestamp without changing its value?
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494832 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
The embedded driver works correctly without creating a Timestamp object, so it should be possible for the client to do the same.
(See SQLTimestamp.newTime(Calendar)
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Attachment: d1816_recycleCleanup_v1.patch
While looking into this issue I noticed that there are several methods in client/am/DateTime.java which do the following two things:
1) Take a "recyclable" Time, Timestamp, or Date object with the apparent
intent of avoiding repeated creation of corresponding java.sql.* objects.
2) Make use of "setXXX" methods that have been deprecated as of JDK 1.1.
As an example, see client/am/DateTime.timeBytesToTime(...).
That said, it looks like the "recyclable" objects are always null which makes the #1 code pretty meaningless (this is confirmed by the fact that the code coverage results show the relevant code is never executed).
I believe I have a fix for this Jira (DERBY-1816), but before working more with it I'm posting d1816_recycleCleanup_v1.patch, which is a pre-patch that does the following:
1) Replaces each of the recyclable Date, Time, and Timestamp arguments with
a recyclable java.util.Calendar object.
2) Modifies the relevant code to call methods on the recyclable Calendar object
instead of on Date, Time, and Timestamp objects. The benefit to doing this
is that we are now using non-deprecated methods.
Note that even with this patch we are still creating a new instance of Time/Timestamp/Date for each method--the cleanup patch does not change that. Instead, the cleanup patch adds the instantiation of a new Calendar object (one per client/am/Cursor) and then (re-)uses that object to replace the deprecated calls. The goal here is not just to replace the deprecated calls, though; I think that having a Calendar object will help resolve this particular Jira (and maybe others), as well.
That said, I was reading through the comments on DERBY-889 and one thing I'm unsure about is how/if timezones need to be handled in this code. When writing the cleanup patch I took a look at the embedded classes and, as far as I can tell, embedded creates a new instance of GregorianCalendar (no timezone info specified) and creates the appropriate date/time object from that (see for example the "newTimestamp()" method in iapi/types/SQLTimestamp, or the "getTimeInMillis()" second in iapi/types/SQLDate). The changes in d1816_recycleCleanup_v1.patch are intended to mimic that behavior in client.
But it's quite possible that I've overlooked something, so I would appreciate any reviews/feedback that anyone might have on this "cleanup" patch.
Note that d1816_recycleCleanup_v1.patch is not intended to change any functionality of the client. The hope for this patch is to keep all behavior the same (even the behavior that is currently wrong) but to make it easier to fix the incorrect behavior with a subsequent patch.
I ran suites.All and derbyall on SUSE Linux with ibm142 and there were no failures.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Attachment: releaseNote.html
Attaching first attempt at a release note.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Derby Info: [Existing Application Impact]
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren closed DERBY-1816.
-------------------------------------
Resolution: Fixed
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren reopened DERBY-1816:
---------------------------------------
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Attachment: d1816_v1.patch
Attaching d1816_v1.patch, which is a fix for this issue. The patch does the following:
1. Separates the timestamp parse logic in client/am/DateTime.java into a new
method called "parseTimestampString()". The new method takes a timestamp
string and a Calendar object, and sets the fields of the Calendar based on
the fields that are parsed from the timestamp string. (This is, I think,
what Dan was suggesting in his most recent comment). The method also
returns the parsed microseconds value since that cannot be set on a
Calendar object (the precision of a Calendar is milliseconds).
2. Modifies timestampBytesToTimestamp(...) to call the new method for
parsing timestamps.
3. Changes the timestampBytesToTime(...) method so that it now parses the
*full* timestamp (via the new parseTimestampString() method) instead of
just parsing the hours, minutes, and seconds. Then a java.sql.Time
object is created from the Calendar object into which the timestamp
string was parsed. This allows us to preserve the sub-second resolution
that is parsed from the timestamp.
4. Re-enables the relevant test case in lang/TimeHandlingTest.java so that
it now runs in client mode.
I ran derbyall and suites.All on a SUSE Linux machine with an earlier version of this patch and the only failure was in derbyall/derbynetmats/maxthreads, which failed with the following diff:
27 del
< Max threads changed to 9000.
27a27
> Reading from process streams timed out..
I don't think that is related to my changes, though.
If anyone has feedback on this fix/approach, that would be great. I plan to re-run derbyall and suites.All as a sanity check to make sure the latest version (_v1 as attached here) still runs cleanly, but am open to suggestions in the meantime...
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren reopened DERBY-1816:
---------------------------------------
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493807 ]
A B commented on DERBY-1816:
----------------------------
Thank you for the link, Dan, it's very helpful.
Since all of the changes that I've made in the clean_v1 patch happen for the getXXX() methods that do not take a Calendar argument, my reading is that the values should be set "according to the time zone of the java virtual machine". My assumption is that this is what happens with the default "new java.util.GregorianCalendar()" constructor, in which case the changes are fine.
Note that for getXXX() methods which *do* take a Calendar object, the client code first calls the version of the method that takes no arguments (which is what the cleanup_v1 patch affects) and then normalizes the result based on the timezone of the received Calendar object. So I think that part should be working correctly, as well.
Please let me know if I've misread something, though...
Thanks again for the pointer.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-1816:
--------------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Existing Application Impact])
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494830 ]
A B commented on DERBY-1816:
----------------------------
One solution that seems to solve this problem is to create a java.sql.Timestamp object from the SQL TIMESTAMP and then use the "Time(long time)" constructor to create a java.sql.Time object, where "time" is retrieved from the java.sql.Timestamp object. For example (in client/am/DateTime.java):
java.sql.Time result = new java.sql.Time(timestampBytesToTimestamp(
buffer, offset, (java.sql.Timestamp)null, encoding).getTime());
That said, though, Java API indicates the following:
"The date components should be set to the "zero epoch" value of January 1, 1970 and should not be accessed."
So we would have to explicitly override the date fields for the resultant java.sql.Time object. Doing so directly via the Time object would require use of deprecated methods (setYear(), setMonth(), setDay()). The other (recommended) option is to use an intermediary Calendar object:
java.sql.Timestamp ts = timestampBytesToTimestamp(
buffer, offset, (java.sql.Timestamp)null, encoding).getTime());
Calendar cal = <cleared Calendar object>;
cal.setTimeInMillis(ts.getTime());
/* Java API indicates that the date components of a Time value must
* be set to January 1, 1970.
*/
cal.set(1970, Calendar.JANUARY, 1);
return new java.sql.Time(cal.getTimeInMillis());
The latter approach (use of Calendar) seems cleaner, but requires either 1) repeated instantiation of a Calendar object, or 2) re-use of some passed in Calendar object, per d1816_recyclableCleanup_v1.patch. The former approach (use of deprecated setXXX() methods) requires fewer changes but seems less wholesome.
Any votes for/against one or the other?
I prefer to use the Calendar approach to avoid deprecated methods, which is why I would like to commit the recyclableCleanup_v1.patch. But I'm open to alternate suggestions.
Either approach requires the additional instantion of a java.sql.Timestamp object for each call to getTime(). Is that acceptable? We could avoid that by isolating the timestamp parsing code into its own method and returning its fields via an array, but I'm not sure if that's better or worse than creating an intermediate Timestamp object...
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren closed DERBY-1816.
-------------------------------------
Resolution: Fixed
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-1816:
--------------------------------------
Attachment: releaseNote.html
scrubbed rn
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493804 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
The DATE/TIME/TIMESTAMP notes here might help:
http://db.apache.org/derby/javadoc/publishedapi/jdbc3/org/apache/derby/jdbc/package-summary.html
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Attachment: d1816_recycleCleanup_v2.stat
d1816_recycleCleanup_v2.patch
Attaching d1816_recycleCleanup_v2.patch, which is pretty much the same as _v1 except that it has been sync'd with the latest codeline (esp. DERBY-889 changes). If I do not hear any objections, I plan to commit this cleanup patch before the end of the day Tuesday (05/22) PST...
derbyall ran cleanly on SUSE Linux with ibm142; suites.All had 13 failures, but all of those show up in the tinderbox results, as well.
Note that the _v2 patch does not resolve this Jira issue; it is simply "pre-patch" cleanup.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B updated DERBY-1816:
-----------------------
Attachment: d1816_recycleCleanup_v3.patch
Committed d1816_recycleCleanup_v3.patch with svn # 540740:
URL: http://svn.apache.org/viewvc?view=rev&rev=540740
The difference between v2 and v3 is that the latter sets the time-related fields to "0" when getting a timestamp value from a SQL date. This more accurately matches the behavior as it was is in Derby prior to the changes for this issue:
_v2:
< + cal.set(year, month, day);
< + return new java.sql.Timestamp(cal.getTimeInMillis());
---
_v3:
> + cal.set(year, month, day, 0, 0, 0);
> + java.sql.Timestamp ts = new java.sql.Timestamp(cal.getTimeInMillis());
> + ts.setNanos(0);
> + return ts;
Other than that the two patches are the same.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494182 ]
Daniel John Debrunner commented on DERBY-1816:
----------------------------------------------
Looking at the network client's implementation of getTimeStamp() with a Calendar I have to say it seems inefficient, confusing and wrong. :-)
This is looking at lines 1020-1031 in client.am.ResultSet.java (which isn't modified by the patch so it's existing code)
Inefficient because it creates two new Calendar objects for every call,that will cause a heavy gc overload and cpu overhead.
Confusing because it uses two Calendar objects (when one will do) and just does strange things:
- The value from the column is set in the targetCalendar but then never used
- The value from the column is set in the defaultCalendar but then never used
- The timezeone offset is calculated using the two calendar objects, and then applied to the long millisecond value obtained from the
java.sql.Timestamp value, but this is what Calendar objects do, so why is this being done explicitly?
- no code comments
Wrong because:
- the passed in calendar is not used to perform the conversion from SQL TIMESTAMP value to java.sql.Timestamp. The passed in Calendar is only used to determine the timezone of the value to be returned (line 1021). However a Calendar object has more meaning than just a time zone, it has behaviour because a Calendar object is an abstract class and thus can have multiple different implementations. The client code is assuming that the Calendar object returned from the static methods Calendar.getInstance() match the Calendar object passed in, this may not be true. If the application passes in a Jewish Calendar implementation for example then most likely this client code will be using a GregorianCalendar to incorrectly perform calculations.
- looking beyond these lines of code, I think the complete conversion is incorrect, even if in this method the passed in Calendar was used. Before these lines of code the value is obtained using the getTimestamp() with no Calendar object, this uses a GregorianCalendar() to convert from the over-the-wire value to a java.sql Timestamp. Thus the conversion would be (if the user supplied Calendar object was used):
YYYY-MM-DD:hh:mm:ss.ffff >> GregorianCalendar >> long milli-seconds >> java.sql.Timestamp >> long milli-seconds >> user supplied Calendar object
I'm think that if the user supplied Calendar object was not an instance of GregorianCalendar then there's a significant chance the wrong result would be returned.
What is required is the same approach as embedded, which is to always perform
YYYY-MM-DD:hh:mm:ss.ffff >> Calendar >> long milli-seconds >> java.sql.Timestamp
where the Calendar is either the user-supplied one or a builtin one, so that the calling order is the other way around, getTimestamp(int) should be calling getTimestamp(int, Calendar).
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1816) Client's ResultSet.getTime() on a SQL
TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
A B closed DERBY-1816.
----------------------
Fix is in trunk (10.3) and I haven't heard any objections to the release note, so closing.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch, releaseNote.html
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a
SQL TIMESTAMP column loses the sub-second resolution and always has a
milli-second value of zero.
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498415 ]
Bryan Pendleton commented on DERBY-1816:
----------------------------------------
I reviewed the patch, and it looks good to me. The code change seems
nice and clean, thanks for adding the comments! I verified that the updated
test fails as expected without the code change, and works as expected
with the code change. Thanks for fixing this bug.
> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1816
> URL: https://issues.apache.org/jira/browse/DERBY-1816
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: A B
> Priority: Minor
> Attachments: d1816_recycleCleanup_v1.patch, d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat, d1816_recycleCleanup_v3.patch, d1816_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP object has its millisecond value for the time portion equal to that for the java.sql.Timestamp value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond value is always zero,
> but java.sql.Time is not a direct mapping to the SQL Type, it's a JDBC type, so when converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of its calls will be commented out
> with a comment with this bug number.
> private void assertTimeEqual(Time tv, Timestamp tsv)
> {
> cal.clear();
> cal.setTime(tv);
>
> int hour = cal.get(Calendar.HOUR_OF_DAY);
> int min = cal.get(Calendar.MINUTE);
> int sec = cal.get(Calendar.SECOND);
> int ms = cal.get(Calendar.MILLISECOND);
>
> // Check the time portion is set to the same as tv
> cal.clear();
> cal.setTime(tsv);
> assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
> assertEquals(min, cal.get(Calendar.MINUTE));
> assertEquals(sec, cal.get(Calendar.SECOND));
> assertEquals(ms, cal.get(Calendar.MILLISECOND)); <<<<<<<<<<<<< FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.