[
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:51 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 _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
> 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)
