[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

["Greg Albiston (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242215#comment-16242215 ] 

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:49 PM:
--------------------------------------------------------------

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, _xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and parsed into Jena XSD Typed Literals. I haven't found any problems with _java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that _LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), when Jena expects them to be preserved. I don't know which is the correct behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement (based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce the format.

{code:java}
    public static final DateTimeFormatter TIME_FORMATTER = DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

    public static final Literal createLocalTime(LocalTime localTime) {
        return ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), XSDBaseNumericType.XSDtime);
    }
{code}

Usage of the _java.time.Duration_ would suggest replacing _javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An issue here is that_ java.time_ distinguishes between dateTime and time with timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid _xsd:time_ literals that throw exceptions if parsed through the wrong _java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The {noformat}java.time{noformat} API is supposed to be ISO-8601 compliant as are {noformat}xsd:duration{noformat}, {noformat}xsd:time{noformat} and {noformat}xsd:dateTime{noformat}.

I've used {noformat}java.time.Duration{noformat} and {noformat}java.time.LocalTime{noformat} in a project and parsed into Jena XSD Typed Literals. I haven't found any problems with {noformat}java.time.Duration{noformat}.

The only issue I've found with {noformat}java.time.LocalTime{noformat} is that {noformat}LocalTime.toString(){noformat} drops zero seconds (i.e. "09:00:00" becomes "09:00"), when Jena expects them to be preserved. I don't know which is the correct behaviour for ISO-8601 but the latter seems to be a {noformat}xsd:time{noformat} requirement (based on 3rd bullet point in [https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a {noformat}java.time.format.DateTimeFormatter{noformat} to enforce the format.

{code:java}
    public static final DateTimeFormatter TIME_FORMATTER = DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

    public static final Literal createLocalTime(LocalTime localTime) {
        return ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), XSDBaseNumericType.XSDtime);
    }
{code}

Usage of the {noformat}java.time.Duration{noformat} would suggest replacing {noformat}javax.xml.datatype.XMLGregorianCalendar{noformat} and {noformat}java.util.Calendar{noformat} in Jena. An issue here is that {noformat}java.time{noformat} distinguishes between dateTime and time with timezone ({noformat}java.time.OffsetDateTime{noformat} and {noformat}java.time.OffsetTime{noformat}) from those without timezones ({noformat}java.time.LocalDateTime{noformat} and {noformat}java.time.LocalTime{noformat}). XSD does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid {noformat}xsd:time{noformat} literals that throw exceptions if parsed through the wrong {noformat}java.time{noformat} object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> --------------------------------------------------------------------
>
>                 Key: JENA-1402
>                 URL: https://issues.apache.org/jira/browse/JENA-1402
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: ARQ
>    Affects Versions: Jena 3.4.0
>            Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>    VALUES (?op1 ?op2) {
>         ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
>         ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
>         ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
>         ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
>         ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
>     }
>     BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)