[
https://issues.apache.org/jira/browse/JENA-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734427#comment-16734427
]
Andy Seaborne commented on JENA-1655:
-------------------------------------
Hi there - yes, the return is not in canonical form, which would be
"0"^^xsd:integer; it is internally the value 0 and tests equal to 0 in all
cases.
It might help in constructing a {{xsd:dateTime}} string because
{{xsd:dateTime}} requires two digits for these components.
Does this difference have an effect other than its observability?
(To be really bizarre, if an operation like +0 is applied, it will be
canonical. It is not unique to this case; the same is true for
{{"+0"^^xsd:integer}} and any other way of writing the value zero as an integer
of derived type).
It can be changed easily enough. The code is at {{XSDFuncOp.dtGetMinutes}}
where it gets {{dts.minute}} from the {{DateTimeStruct}}.
I guess it comes down to what the user community prefers.
> SPARQL time built-ins return non-normalized integer RDF literals
> ----------------------------------------------------------------
>
> Key: JENA-1655
> URL: https://issues.apache.org/jira/browse/JENA-1655
> Project: Apache Jena
> Issue Type: Bug
> Reporter: Dave Griffith
> Priority: Minor
>
> The SPARQL time built-ins (YEAR, MONTH,DAY, HOURS, MINUTES, SECONDS) can
> return integer RDF literals with leading zeros, e.g "00"^^xsd:integer . This
> is largely benign, but can be detected with queries like this:
> {noformat}
> SELECT (xsd:string(minutes("2011-01-10T14:00:13.815-05:00"^^xsd:dateTime)) as
> ?minutes){}
> {noformat}
> which returns "00".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
