You are not going to want to consider the date portion of the Time
object at all. Unfortunately how the various Database vendors handle
this is something i am working to address as it does not line up with
the current specs, and i partially understand why but am not happy
about compatibility, even when switching JDBC drivers and utilizing
the same database.
I will be clarifying this in JDBC 4.1 and then working to get this
addressed in JSR 169 which is an off-shoot of the JDBC specs.
-lance
On Jan 17, 2008, at 9:07 AM, Vemund Østgaard (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559936
#action_12559936 ]
Vemund Østgaard commented on DERBY-3224:
----------------------------------------
It seems that the reason they are not equal is that they represent
the same hour/minute/second, but different dates. AssertEquals in
junit uses <object1>.equals(object2) which for java.sql.Time falls
through to java.util.Date.equals(). This compares the output of
getTime() from both objects,
"thus, two Date objects are equal if and only if the getTime method
returns the same long value for both". Comparing getTime() from my
objects I see:
Time1: -59958280437000 - toString(): 11:06:03
Time2: 36363000 - toString(): 11:06:03
The first one is generated with Time.valueOf("11:06:03") the second
is read from the callable statement. The second one seems to be
11:06:03 after epoch, first one I don't know.
The javadoc for java.sql.Time in jsr169 says: "The date components
should be set to the "zero epoch" value of January 1, 1970 and
should not be accessed." I am not sure if this is enough to consider
it a bug that the date component seems to differ for the two Time
objects.
.
Get Suites.All to run on the phoneME advanced platform
------------------------------------------------------
Key: DERBY-3224
URL: https://issues.apache.org/jira/browse/DERBY-3224
Project: Derby
Issue Type: Test
Components: Test
Environment: Product: phoneME Advanced (phoneme_advanced_mr2-
b34)
Profile: Foundation Profile Specification 1.1
JVM: CVM phoneme_advanced_mr2-b34 (interpreter loop)
Reporter: Vemund Østgaard
Assignee: Vemund Østgaard
Attachments: 3224-diff, 3224-diff.stat, 3224-diffv2, 3224-
diffv2.stat
I'm trying to get suites.All to run on the phoneME advanced platform.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.