Greetings. In the process of working on another patch and running tests
in order to check I didn't break anything, I found that
TypesTest.testDate is failing on my machine (not related to my changes,
an un-patched build fails too). It passes if the session TZ is changed
for example to TZ=C on Linux.
Looks like from commented code on that patch, someone already have
experienced problems with it. For some users retrieving the year from
that date will give 1999, to other 2000, based on the current timezone.
2000-01-01 is an date without an offset, so it should always give 2000.
The reason is that running XmlBeans on a non UTC timezone,
xs:date("2000-01-01") uses internally an instance of java.util.Date on
the UTC timestamp. XmlBeans' SaxonXPath uses Saxon
SequenceTool.convertToJava() that just call getCalendar().getTime() on a
DateValue.
The problem here is the usage of Java old date and time classes that
always have a timezone component attached to it. I think XmlDate should
work internally with another representation like LocalDate and
OffsetDate [1] (or an internal version of it to not add a new dependency).
Any ideas of what is the best way to proceed to fix this. If it were for
me, I would work to get rid of the usage of java.util.Date and work with
JSR 310 classes, but that is a big API change. Maybe someone could have
a better lighter way to solve this error.
Note: I personally don't use XPath with XmlBeans anymore. I used it when
XmlBeans used to have a plug-able service provider interface for XPath
engines and I wrote one for JXPath. When that interface was removed I
resorted to replace my light XPath usage with traversing the document
using the cursor API with not much impact (for me).
[1]
https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/OffsetDate.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
