It turns out there are three JDK-isms here ...
Next clue:
'P59D'^^xsd:duration is equal to 'P2M'^^xsd:duration as well !!
Hint : 59 = 28 + 31 (in in that order, not 31 + 28)
.
.
.
.
It does not matter if the Jena dependency Xerces is on the classpath or
not. In the Oracle JDK, there is an internal Xerces used if no other
DatatypeFactory is provided.
.
.
.
.
1/ The epoch does not begin in 1970-01-01, it begins 1970-02-01
DurationImpl.compare has new GregorianCalendar(1970, 1, 1, ..)
but JAN is zero.
This is minor - it just shifts the bug from 'P31D' to 'P28D'
2/ (line 892 / Java8 ; DurationImpl)
It uses GregorianCalendar.equals(GregorianCalendar) and that can only
meaningfull return lessThan/equal/greaterThan, and not indeterminate
(the right answer).
It should not go near GregorianCalendar.equals until it knows the answer
can't be indeterminate.
3/ It's not xs:yearMonthDuration / xs:dayTimeDuration sensitive.
The obvious fix to precheck fails because this is broken:
Duration d2 = df.newDurationDayTime("P28D") ;
System.out.println(d2.getXMLSchemaType()) ;
throws an exception. Why isn't it xs:yearDayTimeDuration?
if (!yearSet
&& !monthSet
&& daySet
&& hourSet
&& minuteSet
&& secondSet) {
return DatatypeConstants.DURATION_DAYTIME;
requires hour and minute and second to be set but parsing "P28D" does
not do that (it should).
(2) and (3) sort of speaks to Jeremy's point except IMO because
"xsd:dateTime - xsd:dateTime" (in xpath-functions) is a duration, then
xs:duration/xs:duration comparisons are natural and it needs to be
dynamic datatype, not declared datatype. "P1S" < "P1Y" is reasonable.
But the implementation in the Oracle JDK is wrong.
The fix looks like it is for Jena to do it's own testing like
getXMLSchemaType.
Andy
On 20/11/14 02:12, Arthur Keen wrote:
Jeremy,
Thanks. Duration operations are much more 'interesting' than I expected, and I
like your advice on ensuring apples-to-apples comparisons of durations.
Arthur
On Nov 19, 2014, at 4:10 PM, Jeremy J Carroll <[email protected]> wrote:
The IMO correct way to do duration processing, that unfortunately has only got
through the XML bit of the standards process is to use either
http://www.w3.org/TR/xpath-functions/#dt-yearMonthDuration
<http://www.w3.org/TR/xpath-functions/#dt-yearMonthDuration>
or
http://www.w3.org/TR/xpath-functions/#dt-dayTimeDuration
<http://www.w3.org/TR/xpath-functions/#dt-dayTimeDuration>
but not both in the same expression. This avoids the ambiguities.
XPath also defines arithmetic between dates and durations in a useful fashion
Jeremy
On Nov 19, 2014, at 10:57 AM, Arthur Keen <[email protected]> wrote:
Thanks Dave, interesting that RDF 1.1 calls out duration but SPARQL 1.1 does
not. This could be related to SPARQL 1.1 being released before RDF 1.1
On Nov 19, 2014, at 3:20 AM, Dave Reynolds <[email protected]> wrote:
On 19/11/14 05:41, Arthur Keen wrote:
When comparing 28 days to 1 month and 365 days to 1 year in Fuseki 1.1.1
SELECT ("P28D"^^<http://www.w3.org/2001/XMLSchema#duration>
="P1M"^^<http://www.w3.org/2001/XMLSchema#duration> as ?same) {}
--------
| same |
========
| true |
--------
SELECT ("P365D"^^<http://www.w3.org/2001/XMLSchema#duration>
="P1Y"^^<http://www.w3.org/2001/XMLSchema#duration> as ?same) {}
--------
| same |
========
| true |
--------
Shouldn't this be indeterminate in both cases?
xsd:duration was not a supported datatype in RDF 1.0 and isn't included in the
SPARQL 1.1 specification [1] so I wouldn't rely on behaviour here.
SPARQL 1.1 does allow = to be extended to other datatypes but as far as I can
see it doesn't specify how indeterminate values should be handled.
I see that RDF 1.1 does list xsd:duration as a supported datatype (!) which
seems like a terrible idea, no idea why they did that.
I can't speak for whether there is any intention for ARQ to support
xsd:duration fully.
Dave
[1] http://www.w3.org/TR/sparql11-query/#OperatorMapping
