[
https://issues.apache.org/jira/browse/TUSCANY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933384#action_12933384
]
Sebastian Millies commented on TUSCANY-701:
-------------------------------------------
Please reopen.
Consider the following SDO attribute defined in xsd:
<attribute name="validTo" type="date"></attribute>
The attribute has SDOType YearMonthDay, which maps to java.util.Date.
Tthe spec says that its string representation is:
'-'?yyyy'-'mm'-'dd zz?
with zz time zone (('+'|'-')hh':'mm)|'Z' where hh time zone hour, mm
time zone minute.
However, when I retrieve the String value from the data object I get
"2010-10-15 MESZ" which has an incorrect timezone designation.
> Conversion to date types which do not include month can give incorrect results
> ------------------------------------------------------------------------------
>
> Key: TUSCANY-701
> URL: https://issues.apache.org/jira/browse/TUSCANY-701
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SCA-M2
> Environment: Problem exists when running Sun JVM (is not seen on IBM
> JVM)
> Reporter: Brian Murray
> Priority: Minor
> Fix For: Java-SDO-beta1
>
> Attachments: Tuscany701.patch
>
>
> DateConversionTestCase.java made evident an issue corrected in Tuscany-582.
> However, when it was introduced into the Tuscany stream an additional error
> was seen sporadically (repeatedly for a given individual, but for a set of
> individuals only a subset would see the problem). This JIRA will address the
> additional error.
> The reason the problem is seen only by a subset of people is that it is JVM
> specific. When it is seen (as it is with the Sun JVM), the nature of the
> problem is to report Day, Hour, and even Year values as X - 1, where X is the
> correct value. The problem occurs when the requested date format does not
> include a month (e.g. toYear, toDay). The truncated month is assigned a
> value of January, and the Sun JVM may then (depending on the TimeZone,
> northern versus southern hemisphere, and the month in which the test is run)
> change the time to reflect the change to or from daylight savings time.
> The reason it can have an impact on toYear is that toYear() for an input date
> of Wednesday September 6, 2006 03:16:20.382 would result in an interim value
> of Sunday January 1, 2006 00:00:00.000. In the case where an error is seen,
> an adjustment is made for daylight savings time to Saturday December 31, 2005
> 23:00:00.000. As such, toYear erroneously returns a value of 2005 for the
> input date (in the error case).
> Would a committer please assign this issue to me?.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
