You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Ron Gavlin (JIRA)" <tu...@ws.apache.org> on 2007/01/10 21:48:28 UTC
[jira] Created: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
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-M2
Reporter: Ron Gavlin
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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Ron Gavlin (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473720 ]
Ron Gavlin commented on TUSCANY-1044:
-------------------------------------
I thought EMF's org.eclipse.emf.ecore.xml.type.internal.XMLCalendar might be a useful helper class to implement several DataHelperImpl methods including this one. Does the fact that it is labelled as an "internal" EMF package prevent tuscany from using it? This will become a non-issue once tuscany can depend on the Java 5 XMLGregorianCalendar class. Just a thought.
- Ron
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson resolved TUSCANY-1044.
-------------------------------------
Resolution: Fixed
TUSCANY-1044 DataHelperImpl.toDateTime now uses canonical time zone suffix "Z"
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473697 ]
Kelvin Goodson commented on TUSCANY-1044:
-----------------------------------------
Hasan,
its on my radar. I hope to get to it today.
Kelvin.
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Hasan Muhammad (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hasan Muhammad updated TUSCANY-1044:
------------------------------------
Attachment: DateTimeTest.zip
DateTime.patch
I this i have the fix. I have also attached the testcase just for you to verify the patch. I dont think it is necessary to include this testcase in the sdo tests since this is very primitive test.
Hasan
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1044:
------------------------------------
Fix Version/s: (was: Java-SDO-Mx)
Java-SDO-M3
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-M3
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1044:
------------------------------------
Patch Info: (was: [Patch Available])
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1044:
------------------------------------
Patch Info: [Patch Available]
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1044) DataHelperImpl.toDateTime() is not
compliant with spec.
Posted by "Hasan Muhammad (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473271 ]
Hasan Muhammad commented on TUSCANY-1044:
-----------------------------------------
Hi Kelvin,
Did you get a chance to review this patch ?
Cheers, Hasan
> 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-Mx
> Reporter: Ron Gavlin
> Fix For: Java-SDO-Mx
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org