Oh geez, I should have looked more closely at the code, not just where the test failure was happening. Apologies for the confusion (mine!) 😅
It looks like things are working normally again in the latest main commit. Thanks! - Phillip On Fri, Jan 13, 2023 at 4:03 PM Andy Seaborne <[email protected]> wrote: > > > > On 13/01/2023 15:33, Phillip Ross wrote: > >> 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. > > > > I think the test itself doesn't actually reflect the timezone being > > fixed at UTC. > > Yes, one piece of code was calling TimeZone.getDefault(). > > > The test is ASSUMING the JVM timezone is UTC (since it > > doesn't explicitly specify/set the JVM timezone), > > Not the test - the code being tested. > > Writing no timezone in SPARQL is not the same as writing with timezone. > > But the ways it is not the same differ - XSD and F&O differ! > > Comparison follows XSD and has the "14 hour" rule. > Sorting follows F&O (implicit-timezone). > > > BUT that won't > > necessarily be the case when the test runs. If the operating > > environment has the timezone set to UTC then all is good. But if the > > build is being done in a dev environment that has a locale and > > timezone set to something other than UTC, the test will fail since the > > comparison will use the local timezone rather than UTC (since the test > > doesn't specify it). > > > > Timezones are fun! :) If my explanation still doesn't make sense or > > it sounds like I'm crazy, I can maybe throw together an example which > > attempts to better illustrate the issue. It's relatively easy to > > reproduce the issue: > > > > TZ=US/Eastern mvn -pl :jena-arq verify > > > > versus > > > > TZ=UTC mvn -pl :jena-arq verify > > > > The former fails while the later succeeds. > > Currently because of a different timezone related issue. > > The first is: > https://github.com/apache/jena/pull/1714/commits/9c9e8ee02e > XSDFuncOp line 1763 > > > > > > >> > >> 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 <[email protected]> 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
