db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date
Date Fri, 10 Mar 2006 16:49:39 GMT
    [ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369883 ] 

Bryan Pendleton commented on DERBY-889:

> the cal field can be set by other calls 

I am continuing to struggle with the requirements for this issue, I'm afraid.

The ResultSet javadoc defines 4 overloads of getTimestamp():
 - getTimestamp(int columnIndex)
 - getTimestamp(int columnIndex, Calendar cal)
 - getTimestamp(String columnName)
 - getTimestamp(String columnName, Calendar cal)

The javadoc for the methods which take Calendar arguments say:
         This method uses the given calendar to construct an appropriate millisecond value
for the 
         timestamp if the underlying database does not store timezone information.
Which is pretty darn terse, unfortunately, and doesn't give us much guidance.

With the current unpatched code, I believe, the embedded driver was already not using the
cached connection from the ConnectionChild if the caller passed in their own Calendar
object (I will do more testing to confirm this). So I wasn't  changing that flow. The only
case where we use the cached Calendar object is when we don't already have a Calendar object.

What EmbedResultSet..getTimestamp() does is to call the underlying DataValueDescriptor's
getTimestamp() call, passing
 - the Calendar object that the application gave us, if it gave us one, or
 - the Calendar object that was cached in ConnectionChild, otherwise

Now, the SqlTime DataValueDescriptor already knows how to handle the case of a NULL
Calendar object; in that case it allocates a fresh new Calendar object and initializes it
with today's date and time, then fills in the time information from the database column value.
This is the desired behavior, as I understand it, so all I was doing in the patch was to
remove the cached Calendar object which was getting in the way of this behavior (and
which wasn't providing any other useful behavior that I could see other than the performance
optimization of not needing to allocate a new Calendar object).

However, I realize as a result of your comments that there are a number of other issues here:
 - how do DataValue objects other than SqlTime handle the Calendar object which is passed
   into the getTimestamp() method. I will need to research this some more.
 - what is the intended semantic of the JDBC API when the client application passes in a
   Calendar object to getTimestamp() while fetching a value from a TIME field. Is the
   intended behavior:
   - that we should preserve the date information in the client's Calendar object?
   - that we should overwrite the date information in the client's Calendar object with
     the current date and time?

Sigh. I've got a lot more things to study and learn about. That's a good thing :) But if you
provide any additional guidance in here, either from the SQL standard, or from other areas,
that would be most helpful.

> with client getTimestamp on a TIME column will print the date  1900-01-01 instead of
the current date
> -----------------------------------------------------------------------------------------------------
>          Key: DERBY-889
>          URL: http://issues.apache.org/jira/browse/DERBY-889
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Versions:,,,
>     Reporter: Kathey Marsden
>     Assignee: Bryan Pendleton
>  Attachments: derby-889.diff
> On client getTimestamp on a TIME column will print date   1900-01-01 instead of the current
date like the embedded driver.
> To repro run the DERBY-877 repro without specifying a file.encoding
> java TestEnc derbynetclient
> [snip]
>         getString:      16:27:35
>         getTimeStamp:   1900-01-01 16:27:35.0
>         getTime:        16:27:35
>         getDate         Exception SQLSTATE:null  (EXPECTED)
> With Embedded  it prints the current date for getTimestamp
> java TestEnc  derby
>         getString:      16:27:35
>         getTimeStamp:   2006-01-28 16:27:35.0
>         getTime:        16:27:35
>         getDate         Exception SQLSTATE:22005  (EXPECTED)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message