You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@poi.apache.org by Robert Marcano <ro...@marcanoonline.com.INVALID> on 2021/12/30 02:43:26 UTC

XmlBeans test TypesTest.testDate fails on non UTC TZ

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: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: XmlBeans test TypesTest.testDate fails on non UTC TZ

Posted by Robert Marcano <ro...@marcanoonline.com.INVALID>.

On 12/30/21 5:35 PM, Andreas Beeker wrote:
> Hi,
> 
> I've activated the POI rule set for forbidden APIs locally and there are 
> several locations popping up which are related to this.
> I currently don't know yet on how to fix this, but my idea would be 
> either ...
> a) to use the XmlOptions somehow to set the default timezone (and 
> locale) for dates - the goal is to avoid ThreadLocals. Or ...
> b) for literals without timezone, we try to use the system/local timezone
> 
> As we do a) in POI - I would prefer this. And to minimize confusion, I 
> would raise the version to 6.0.0 and don't provide a j.u.Date and JSR 
> 310 support in parallel if we choose JSR 310.

I noticed that the test was recently updated, but it is just checking 
the offset of the current timezone and asserting for the 1999 or 2000 
year. IMHO the test should be changing the current Timezone temporally 
(for two or mote timezones) and not running one of two different 
branches of code depending on the test environment.

By the way the internal use of java.time.Date instances is still a 
problem, because on that test asserting for the year on a GDate is gives 
the wrong year.

   GDate gdate = ((XmlDate) res[0]).getGDateValue();
   assertEquals(gdate.getYear(), 2000);

Test that using `export TZ=US/Eastern`

I will add a JIRA for this problem in order to continue the discussion 
there.

> 
> Regarding the XPath plugins, I guess XmlCursor usage is more performant 
> - if you need a kind of plugin support again, we can work something out.

Currently I don't need the plugin, since I don't use anymore XMLBeans' 
XPath support. I fond and that time weird that JXPath wasn't supported 
at that time. I didn't want another XPath processor like Saxon, because 
Apache Commons JXPath was already one in my application. I even remember 
offering my service provider implementation but sadly got no response (a 
lot of time ago)

> 
> Andi
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: XmlBeans test TypesTest.testDate fails on non UTC TZ

Posted by Andreas Beeker <ki...@apache.org>.

Hi,

I've activated the POI rule set for forbidden APIs locally and there are several locations popping up which are related to this.
I currently don't know yet on how to fix this, but my idea would be either ...
a) to use the XmlOptions somehow to set the default timezone (and locale) for dates - the goal is to avoid ThreadLocals. Or ...
b) for literals without timezone, we try to use the system/local timezone

As we do a) in POI - I would prefer this. And to minimize confusion, I would raise the version to 6.0.0 and don't provide a j.u.Date and JSR 310 support in parallel if we choose JSR 310.

Regarding the XPath plugins, I guess XmlCursor usage is more performant - if you need a kind of plugin support again, we can work something out.

Andi



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: XmlBeans test TypesTest.testDate fails on non UTC TZ

Posted by PJ Fanning <fa...@yahoo.com.INVALID>.

Could you just raise a separate issue for the testDate (in JIRA)? For the sake of the patch you are working, it is best not to complicate it by trying to fix an unrelated issue. If you want to submit a separate for the testDate issue, that is fine.

On Thursday 30 December 2021, 02:43:42 GMT, Robert Marcano <ro...@marcanoonline.com.invalid> wrote:

[1]
https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/OffsetDate.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org