[jira] Commented: (TUSCANY-1044) DataHelperImpl.toDateTime() is not compliant with spec.

["Sebastian Millies (JIRA)" <de...@tuscany.apache.org>]

    [ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929591#action_12929591 ] 

Sebastian Millies commented on TUSCANY-1044:
--------------------------------------------

Please reopen this issue, it appears not to have been fixed.

Consider an SDO attribute defined in xsd:    <attribute name="validTo" type="date"></attribute>
This xsd:date maps to SDO type YearMonthDay, with a string representation of 
'-'?yyyy'-'mm'-'dd zz?
 with zz time zone (('+'|'-')hh':'mm)|'Z' where hh time zone hour, mm time zone minute.

However, when I obtain a java.util.Date, set it in the SDO and look at the string value using Tuscany 1.6, 
I get something with a non-compliant timezone value:
 
     // obtain a date with year, month, day only in default TZ
    Calendar cal = new GregorianCalendar();
    cal.set( 2010, Calendar.OCTOBER, 15, 0, 0, 0 );
    cal.set( Calendar.MILLISECOND, 0 );
    Date date = cal.getTime();
 
    sdo.setDate( "validFrom", date );
    String str = sdo.getValidFrom();

The result is "2010-10-15 MESZ", where the "MESZ" is wrong.

> > 
> > Then str = 2010-10-15[ MESZ]


> DataHelperImpl.toDateTime() is not compliant with spec.
> -------------------------------------------------------
>
>                 Key: TUSCANY-1044
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1044
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SDO Implementation
>    Affects Versions: Java-SDO-Next
>            Reporter: Ron Gavlin
>             Fix For: Java-SDO-beta1
>
>         Attachments: DateTime.patch, DateTimeTest.zip
>
>
> Ron,
>    I think you are correct.  The spec says ...
> The String representation of DateTime, Duration, Time, Day, Month, MonthDay,
> Year, YearMonth, and YearMonthDay follows the lexical representation defined
> in XML Schema for the corresponding data types: dateTime, duration, time,
> gDay, gMonth, gMonthDay, gYear, gYearMonth, and Date respectively.
> and the XML schema definition at
> http://www.w3.org/TR/xmlschema-2/#dateTime-timezones seems to be overriden
> by the errata at http://www.w3.org/2001/05/xmlschema-errata#e2-45 which
> gives ...
> The lexical representation of a timezone is a string of the form: (('+' |
> '-') hh ':' mm) | 'Z', where *hh* is a two-digit numeral (with leading zeros
> as required) that represents the hours, *mm* is a two-digit numeral that
> represents the minutes, '+' indicates a nonnegative duration, and '-'
> indicates a nonpositive duration. The mapping so defined is one-to-one,
> except that '+00:00', '00:00', and 'Z' all represent the same zero-length
> duration timezone, UTC; 'Z' is its canonical representation.
>   so please raise a JIRA, and of course I have to say it ... a fix would be
> great too ;-)
> Cheers, Kelvin.
> On 09/01/07, Ron Gavlin <rg...@yahoo.com> wrote:
> >
> > Greetings,
> >
> > Based on my reading of the spec, DataHelperImpl.toDateTime(Calendar)
> > should return a String compatible with the XML Schema dateTime. Consider the
> > code snippet below:
> >
> > import commonj.sdo.helper.DataHelper;
> >
> > System.out.println(DataHelper.INSTANCE.toDateTime(
> > DataHelper.INSTANCE.toCalendar("2007-01-01T00:00:00.200Z"))
> >
> > This snippet prints the result:
> > (java.lang.String) 2007-01-01T00:00:00.200 GMT
> >
> > instead of
> > (java.lang.String) 2007-01-01T00:00:00.200Z
> >
> > The GMT suffix seems incorrect to me. The following code supports this
> > assertion by throwing an IllegalArgumentException when it encounters the "
> > GMT" suffix generated by the DataHelper.toDateTime() method.
> >
> > import javax.xml.datatype.DatatypeFactory;
> >
> > DatatypeFactory.newInstance().newXMLGregorianCalendar("2007-01-01T00:00:
> > 00.200 GMT");
> >
> > Do you agree this is a bug? If so, I'll be glad to open a JIRA.
> >
> > - Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.