[
https://jira.duraspace.org/browse/DS-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25193#comment-25193
]
DSpace @ LyNcode edited comment on DS-1195 at 6/18/12 11:52 PM:
----------------------------------------------------------------
Hi Ivan Masár,
my fault, i did not gave a good explanation of the Oracle problem, but i really
don't have sure of it. Local timezone is not the point (so it is not a DSpace
problem). The problem is with the interface between DSpace and Oracle (the
oracle jdbc driver specifics), maybe with the jvm (system)/oracle timezone.
My point is here:
parameters: 341,0001-01-01 01:00:00.0,10000-01-01 00:59:59.999 [1]
The initial date 9999-12-31 (assumed by OAICAT) is transformed to 10000-01-01,
raising the oracle jdbc driver exception "Year out of range".
"Oracle Database can store dates in the Julian era, ranging from January 1,
4712 BCE through December 31, 9999 CE (Common Era, or 'AD'). Unless BCE ('BC'
in the format mask) is specifically used, CE date entries are the default." [2]
So what is happening is related with timezones. Oracle database is getting the
timestamp not into GMT but into another timezone (GMT+1 in this case) -
something is happening, i can't well explain but the log at
DatabaseManager.query is also formatting this date to an GMT+1 (maybe the
defined jvm TimeZone?)
Nevertheless, in our services, all system timezones are configured as GMT, with
this, one have guaranteed that this date conversions problems does not happen.
Maybe another workaround would solve the problem (using the date parse
functions available in Oracle/PostgreSQL - allows one to specify the timezone
giving time as a string - with this it will be possible to have control over
those conversions).
-- Resources
[1] http://sourceforge.net/mailarchive/message.php?msg_id=29421592
[2] http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#i1847
was (Author: lyncode):
Hi Ivan Masár,
my fault, i did not gave a good explanation of the Oracle problem. Local
timezone is not the point (so it is not a DSpace problem). The problem is with
the interface between DSpace and Oracle (the oracle jdbc driver specifics),
maybe with the jvm (system)/oracle timezone.
My point is here:
parameters: 341,0001-01-01 01:00:00.0,10000-01-01 00:59:59.999 [1]
The initial date 9999-12-31 (assumed by OAICAT) is transformed to 10000-01-01,
raising the oracle jdbc driver exception "Year out of range".
"Oracle Database can store dates in the Julian era, ranging from January 1,
4712 BCE through December 31, 9999 CE (Common Era, or 'AD'). Unless BCE ('BC'
in the format mask) is specifically used, CE date entries are the default." [2]
So what is happening is related with timezones. Oracle database is getting the
timestamp not into GMT but into another timezone (GMT+1 in this case) -
something is happening, i can't well explain but the log at
DatabaseManager.query is also formatting this date to an GMT+1 (maybe the
defined jvm TimeZone?)
Nevertheless, in our services, all system timezones are configured as GMT, with
this, one have guaranteed that this date conversions problems does not happen.
Maybe another workaround would solve the problem (using the date parse
functions available in Oracle/PostgreSQL - allows one to specify the timezone
giving time as a string - with this it will be possible to have control over
those conversions).
-- Resources
[1] http://sourceforge.net/mailarchive/message.php?msg_id=29421592
[2] http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#i1847
> DSpace OAI with Oracle
> ----------------------
>
> Key: DS-1195
> URL: https://jira.duraspace.org/browse/DS-1195
> Project: DSpace
> Issue Type: Bug
> Components: OAI-PMH
> Affects Versions: 1.8.2
> Environment: Oracle Database
> Reporter: DSpace @ LyNcode
> Priority: Critical
> Attachments: patch-dspace-oai-oracle-db.diff
>
>
> Patch to solve this problem:
> http://sourceforge.net/mailarchive/message.php?msg_id=29421592
> The new OAICAT version does not solve this problem.
> In attachment, you could see a patch to apply over the dspace-oai source:
> $ cd [DSPACE-SOURCE]
> $ patch -p0 < [PATH-TO]/patch-dspace-oai-oracle-db.diff
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
