You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Phillip Ross <ph...@gmail.com> on 2023/01/08 05:30:38 UTC
possible bug in adjust impl or test
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
Re: possible bug in adjust impl or test
Posted by Phillip Ross <ph...@gmail.com>.
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 <an...@apache.org> 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 <an...@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
Re: possible bug in adjust impl or test
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@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
Re: possible bug in adjust impl or test
Posted by Phillip Ross <ph...@gmail.com>.
> 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. The test is ASSUMING the JVM timezone is UTC (since it
doesn't explicitly specify/set the JVM 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.
>
> 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 <an...@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
Re: possible bug in adjust impl or test
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@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
Re: possible bug in adjust impl or test
Posted by Phillip Ross <ph...@gmail.com>.
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 <an...@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
Re: possible bug in adjust impl or test
Posted by Andy Seaborne <an...@apache.org>.
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