[
https://issues.apache.org/jira/browse/XMLBEANS-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470181#comment-17470181
]
PJ Fanning commented on XMLBEANS-588:
-------------------------------------
[~kiwiwings] has already posted this in an email -
[https://markmail.org/thread/6snnn6he42tltpa5#query:+page:1+mid:gulz5xetojwjenqi+state:results]
My guess is that XmlBeans classes like XmlDate, XmlDateTime (and lots of other
date/time classes) will need to be rewritten to use allow non-zoned date/times
as well as zoned. And that this could all turn into a pretty large task. I
think there is a lot more to this than rewriting just _SaxonXPath_ class{_}.{_}
> GDate can return diferent values on different current timezones
> ---------------------------------------------------------------
>
> Key: XMLBEANS-588
> URL: https://issues.apache.org/jira/browse/XMLBEANS-588
> Project: XMLBeans
> Issue Type: Bug
> Reporter: Robert Marcano
> Priority: Major
>
> When using Saxon XPath processor in order to retrieve a date value for
> example:
> {{XmlObject o = XmlObject.Factory.parse("<a/>");}}
> {{XmlObject[] res = o.selectPath("xs:date(\"2000-01-01\")");}}
> {{GDate gdate = ((XmlDate) res[0]).getGDateValue();}}
> {{assertEquals(gdate.getYear(), 2000);}}
> fails is the current timezone has a negative offset, for example US/Eastern.
> The problem arises because _SaxonXPath_ uses internally a method that returns
> _java.util.Date_ instances and those always has a timezone attached. Maybe
> the _GDate_ should not come from a Date resulting from the invocation of
> _SequenceTool.convertToJava()_ in _SaxonXPath_
> {{GDate}} should contain the exact date without timezone problems, it could
> probably should not be instantiated from a _Date_ coming from Saxon, but from
> the native Saxon _Date_ representation
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]