Thanks -
In fact, it's not the new code in error.
The implementation of fn:adjust-datetime-to-timezone has local locale
sneaking into it.
I think that "local" is a bit meaningless in a webfacing system (or just
a system in a large organisation across geographies) and the "implicit"
(as defined by xpath/xquery functions and operators) timezone should be
fixed as 00:00 (UTC) which the test reflects.
Andy
On 09/01/2023 00:34, Phillip Ross wrote:
Hi Andy, the following is some output of the failure:
[INFO] Running org.apache.jena.sparql.expr.TS_Expr
[ERROR] Tests run: 1437, Failures: 1, Errors: 0, Skipped: 0, Time
elapsed: 0.23 s <<< FAILURE! - in org.apache.jena.sparql.expr.TS_Expr
[ERROR] adjust_4(org.apache.jena.sparql.expr.TestFunctions2) Time
elapsed: 0.003 s <<< FAILURE!
java.lang.AssertionError: Not same value: Expected:
"2022-12-21T05:05:07Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> :
Actual =
"2022-12-21T05:05:07-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>
at
org.apache.jena.sparql.expr.TestFunctions2.test(TestFunctions2.java:593)
at
org.apache.jena.sparql.expr.TestFunctions2.adjust_4(TestFunctions2.java:497)
The -05:00 offset in the output matches my current timezone
(US/Eastern) and will change if I change the timezone with the TZ
environment variable. If I set the timezone to GMT or UTC the test
succeeds.
On Sun, Jan 8, 2023 at 3:19 PM Andy Seaborne <a...@apache.org> wrote:
Hi Phillip,
What the test failure say?
Andy
On 08/01/2023 05:30, Phillip Ross wrote:
hello and happy new year!
I was eager to experiment with the adjust function and just tried to
build main. Unfortunately I experienced test failures in jena-arq
module adjust_4 test, but only when the timezone is not GMT, UTC, or
offset 00:00. I get the same failures on both MacOS and Ubuntu.
Apologies for not taking the time to troubleshoot deeper, but I
figured I'd send a quick heads up since it was a fairly fresh PR
merge.
Thanks!
- Phillip
