[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930342#comment-16930342
]
Andy Seaborne edited comment on JENA-1402 at 9/16/19 9:05 AM:
--
Maybe good - although that is going to make working with the value messy if the
java object class is hopping around. I'll experiment with a few tests cases to
see if Period works for a Year-Month java.time.duration. The javax.xml types do
work and are more focuesdon xsd, just for that duration bug
This is the code for XSD support as a standalone library with minimal
dependencies.
[https://github.com/afs/xsd4ld]
It is the java "value" for the datatype that is the part we are discusssing
here.
was (Author: andy.seaborne):
Maybe good - although that is going to make working with the value messy if the
java object class is hopping around. I'll experiment with a few tests cases to
see if Period works for a Year-Month java.time.duration. The javax.xml types do
work and are more focues on xsd, just for that duration bug.
> 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
>Priority: Major
>
> 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"^^
> "PT1M10S"^^)
> ("PT2M3.123S"^^
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448024#comment-16448024
]
Bruno P. Kinoshita edited comment on JENA-1402 at 4/23/18 11:56 AM:
At work we migrated a forecast system using Joda to Java 8 time API. Pretty
much everything worked, except some classes that were missing (two IIRC) that
were available in [three-thirteen|http://www.threeten.org/threeten-extra/].
Perhaps there could be a third temporary/phase-out alternative... though it
could look a bit too hacky? One could create an adapter layer for Jena users to
experiment the Java 8 time package and see if that works OK before moving.
Add the following JVM argument when running the next class:
-Djavax.xml.datatype.DatatypeFactory=org.apache.jena.atlas.data.WrappedDurationDatatypeFactory.
{code:java}
// random module that I was reading the code...
package org.apache.jena.atlas.data;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;
public class TestingXmlJava8Durations {
public static void main(String... args) throws
DatatypeConfigurationException {
String lex1 = "PT1M3.123S";
String lex2 = "PT0M10.123S";
DatatypeFactory factory = DatatypeFactory.newInstance();
System.out.println(factory.getClass()); // to get the factory class
name...
Duration dt1 = factory.newDuration(lex1);
Duration dt2 = factory.newDuration(lex2);
System.out.println(dt1);
System.out.println(dt2);
System.out.println();
Duration dt3 = dt1.subtract(dt2);
System.out.println(dt3);
System.out.println();
}
}
{code}
{code:java}
package org.apache.jena.atlas.data;
import java.math.BigDecimal;
import java.util.Calendar;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeConstants.Field;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;
public class WrappedXmlDuration extends Duration {
private java.time.Duration javaDuration;
private DatatypeFactory factory;
public WrappedXmlDuration(Duration xmlDuration) throws
DatatypeConfigurationException {
javaDuration =
java.time.Duration.ofMillis(xmlDuration.getTimeInMillis(Calendar.getInstance()));
factory =
DatatypeFactory.newInstance("org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl",
TestingXmlJava8Durations.class.getClassLoader());
}
public java.time.Duration getWrapped() {
return javaDuration;
}
@Override
public int getSign() {
if (javaDuration.isZero())
return 0;
return javaDuration.isNegative() ? -1 : 1;
}
@Override
public Number getField(Field field) {
throw new RuntimeException("Not implemented");
}
@Override
public boolean isSet(Field field) {
throw new RuntimeException("Not implemented");
}
@Override
public Duration add(Duration rhs) {
java.time.Duration otherDuration =
java.time.Duration.ofMillis(rhs.getTimeInMillis(Calendar.getInstance()));
java.time.Duration added = javaDuration.plus(otherDuration);
return factory.newDuration(added.toMillis());
}
@Override
public void addTo(Calendar calendar) {
throw new RuntimeException("Not implemented");
}
@Override
public Duration multiply(BigDecimal factor) {
java.time.Duration multiplied =
javaDuration.multipliedBy(factor.longValue());
return factory.newDuration(multiplied.toMillis());
}
@Override
public Duration negate() {
java.time.Duration negated = javaDuration.negated();
return factory.newDuration(negated.toMillis());
}
@Override
public Duration normalizeWith(Calendar startTimeInstant) {
throw new RuntimeException("Not implemented");
}
@Override
public int compare(Duration duration) {
java.time.Duration otherDuration = java.time.Duration
.ofMillis(duration.getTimeInMillis(Calendar.getInstance()));
return javaDuration.compareTo(otherDuration);
}
@Override
public int hashCode() {
return javaDuration.hashCode();
}
@Override
public String toString() {
return javaDuration.toString();
}
}
{code}
{code:java}
package org.apache.jena.atlas.data;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.util.GregorianCalendar;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;
import javax.xml.datatype.XMLGregorianCalendar;
public class WrappedDurationDatatypeFactory extends DatatypeFactory {
private DatatypeFactory factory;
public WrappedDurationDatatypeFactory() throws
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"^^
>
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"^^
>
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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:
