xsd:dayTimeDuration comparison on decimals

I’m seeing fractional portions compare incorrectly.

According to http://www.datypic.com/sc/xsd/t-xsd_dayTimeDuration.html I think this should work.

select ((?d1 > ?d2) as ?d1IsBigger) ((?d2 > ?d1) as ?d2IsBigger) ((?d1 + ?d2) as ?sum)
WHERE {
  BIND("PT0.5123S"^^xsd:dayTimeDuration as ?d1 )
  BIND("PT0.4321S"^^xsd:dayTimeDuration as ?d2 )
}

Notice in the results that both tests ?d1IsBigger and ?d2IsBigger report false. However the addition operation gives the expected result.

{
  "head" : {
    "vars" : [
      "d1IsBigger",
      "d2IsBigger",
      "sum"
    ]
  },
  "results" : {
    "bindings" : [
      {
        "d1IsBigger" : {
          "datatype" : "http://www.w3.org/2001/XMLSchema#boolean",
          "type" : "literal",
          "value" : "false"
        },
        "d2IsBigger" : {
          "datatype" : "http://www.w3.org/2001/XMLSchema#boolean",
          "type" : "literal",
          "value" : "false"
        },
        "sum" : {
          "datatype" : "http://www.w3.org/2001/XMLSchema#dayTimeDuration",
          "type" : "literal",
          "value" : "PT0.9444S"
        }
      }
    ]
  }
}

Hi Austin,

This answer seems to be correct with respect to the definition of duration
ordering in the XSD spec [1] where ordering ignores fractional seconds (in
this case we are simply using javax.xml.datatype.Datatype which
implements this definition and says these durations are equal). However,
XPath spec defines a more straight-forward comparison definition [2] where
you'd get your expected result. I created a ticket (#4300) for us to adopt
this definition for comparison.

The workaround until then would be to use an expression like this for
comparison:

(?d2 - ?d1) * 1000 > "PT0.0S"^^xsd:dayTimeDuration

This would give you millisecond precision for comparison. You can multiply
with a larger number to increase the precision.

Best,
Evren

[1] https://www.w3.org/TR/xmlschema11-2/#duration
[2] https://www.w3.org/TR/xpath-functions-3/#func-dayTimeDuration-less-than

Thanks for looking into it @evren!