Bug 1009498

Summary:	[HHH-8517] ResultSet#getDate includes time in oracle12c JDBC
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Martin Simka <msimka>
Component:	Hibernate	Assignee:	Brett Meyer <brmeyer>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Zbyněk Roubalík <zroubali>
Severity:	medium	Docs Contact:	Russell Dickenson <rdickens>
Priority:	unspecified
Version:	6.2.0	CC:	dosoudil, lcosti, theute
Target Milestone:	ER4
Target Release:	EAP 6.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	HHH-8517 ResultSet#getDate includes time in oracle12c JDBC https://hibernate.atlassian.net/browse/HHH-8517 Hibernate relies on JDBC's ResultSet#getDate to populate an entity's Date properties during a query. Most DBs strip out the time for that call, but oracle12c appears to keep it (incorrectly). Adding handling to ensure it's stripped.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-15 16:22:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1010467, 1011861

Description Martin Simka 2013-09-18 14:37:22 UTC

We've added new oracle12c to our QA lab and this test fails only on this oracle instance. It could be only db configuration issue, but I haven't found reason why it fails.

Stacktrace

org.junit.ComparisonFailure: expected:<July 21, 1905 1[2]:00:00 AM EST> but was:<July 21, 1905 1[0]:00:00 AM EST>
	at org.junit.Assert.assertEquals(Assert.java:125)
	at org.junit.Assert.assertEquals(Assert.java:147)
	at org.hibernate.test.annotations.EntityTest.testTemporalType(EntityTest.java:381)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
	at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:63)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)

https://hibernate.atlassian.net/browse/HHH-8517

Comment 1 Martin Simka 2013-09-19 14:52:57 UTC

@Brett fyi:
I've checked timezone setting on all oracle databases we certify for EAP 6.1.1/ 6.2.0

SELECT DBTIMEZONE FROM DUAL;
oracle12c, oracle11gR1RAC, oracle11gR2RAC: +00:00
oracle11gR1, oracle11gR2: -04:00

SELECT SESSIONTIMEZONE FROM DUAL;
all: Europe/Prague (-- that is what I'd expect)

SELECT CURRENT_TIMESTAMP FROM DUAL:
all: my current time (I'd expect this too)

so from my point of view it's not configuration issue
(or I'm lost in timezones of dbs, jenkins hosts, ...)

Comment 2 Brett Meyer 2013-09-19 18:30:25 UTC

Martin, thanks for checking.  But, we did find a legitimate "issue" due to inconsistency in the new JDBC driver.

We rely on JDBC's ResultSet#getDate to populate an entity's Date properties during a query. Most DBs strip out the time for that call, but oracle12c appears to keep it (incorrectly). Adding handling to ensure it's stripped.

Comment 3 Brett Meyer 2013-09-19 19:23:21 UTC

Correct upstream, but holding off for EAP 6.3.0.

Comment 4 Brett Meyer 2013-09-25 15:54:47 UTC

Actually, this will go into EAP 6.2.0 ER4's upgrade to Hibernate ORM 4.2.6.Final in 1010467.

Comment 8 Martin Simka 2013-10-14 10:28:40 UTC

verified on EAP 6.2.0.ER5

Comment 9 Brett Meyer 2013-10-24 14:42:33 UTC

1022581 will revert this change and instead correct the failing test.  A community member pointed out a tricky regression in our approach.  See https://hibernate.atlassian.net/browse/HHH-8617 for more info.

What do we do to this ticket?