On 1/29/06, Kathey Marsden (JIRA) <[email protected]> wrote:
[ http://issues.apache.org/jira/browse/DERBY-877?page=all ]
Kathey Marsden updated DERBY-877:
---------------------------------
Attachment: derby-877.diff
The patch fixes issues with getString, getTimeStamp, getDate and getTime on TIMESTAMP, DATE and TIME columns when the client JVM encoding does not match the server encoding for the characters being evaluated in DateTime.java methods
- Changes the following methods in DateTime.java to take encoding parameter and create string based on encoding.
dateBytesToDate, timeBytesToTime, timeBytesToTimeStamp, dateBytesToTimeStamp, timestampBytesToDate, timestampBytesToTime
- Changes calling code to pass column encoding and throw SQLExceptions for UnsupportedEncoding exceptions if thrown from the methods above.
Tests: derbyall passed as did the repro attached to this issue on Windows with Sun JDK 1.5 (note repro won't run with jdk 1.4.2).
I still do not have a solution for testing within the harness on systems where the JVM encoding does match the server encoding.
Any ideas on testing solutions are welcome.
How about using the remote host stuff? Then you can set up the network server on a machine with a different encoding? I'm almost ready with a patch to DERBY-871 (the securityManager with useprocess stuff broke the remote host stuff).
Of course, I'd still need to fix the harness to correctly handle the different encoding
(DERBY-658 I had at one point started on this but got side-tracked.)...
