BTW: What about client and server in different timezones? Bernt M. Johnsen wrote: > Bryan Pendleton (JIRA) wrote: >> [ >> http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12432344 >> ] >> >> Bryan Pendleton commented on DERBY-889: >> --------------------------------------- >> >> Hi Dan, thanks for the feedback and pointers. >> >> Yes, behavior (C): the current date at the time the getTimestamp() is >> called, is the >> behavior that I was attempting to achieve with the patch. > > I would say C is an ok approach from a practical point of view, although D > would be the ideal solution, > since then the following two cases would have equal behaviour: > > PreparedStatement P = c.prepareStatement("select timeCol from > verylongendcomplexoperation"); > ResultSet rs = p.execute(); > java.sql.Timestamp ts = rs.getTimestamp(1); > > and > > PreparedStatement P = c.prepareStatement("select CAST(timeCol AS TIMESTAMP) > from verylongendcomplexoperation"); > ResultSet rs = p.execute(); > java.sql.Timestamp ts = rs.getTimestamp(1); > >> Am I understanding correctly that your idea with DERBY-1811 is to split this >> issue >> into a client issue (DERBY-889) and an embedded issue (DERBY-1811)? That >> seems like a good plan to me. >> >> Regarding your critique of the EmbedResultSet change, I agree that it is >> undesirable >> to lose the optimization of re-using the shared Calendar object, and I agree >> that it >> leaves a hole in that it doesn't actively ensure any particular value for >> the DATE portion >> in the case of getTimestamp(<TIME column>, cal). >> >> It sounds like your preferred fix for DERBY-1811 would be: >> - always re-use the cached calendar object if the user does not pass one in >> - set the date portion of the calendar object (either the cached one or the >> user-provided one) >> to contain the current date when converting a TIME value into a TIMESTAMP >> >> Thanks for your continued review and your help understanding the intended >> behavior. >> >> >>> 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 >>> Issue Type: Bug >>> Components: Network Client >>> Affects Versions: 10.1.2.1, 10.1.2.2, 10.2.1.0, 10.1.3.0 >>> Reporter: Kathey Marsden >>> Assigned To: Bryan Pendleton >>> Attachments: derby-889-updated-Aug-2006.diff, 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] >>> COLUMN 2:TM TIME >>> 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 >>> COLUMN 2:TM TIME >>> getString: 16:27:35 >>> getTimeStamp: 2006-01-28 16:27:35.0 >>> getTime: 16:27:35 >>> getDate Exception SQLSTATE:22005 (EXPECTED) > >
-- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
