Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Negative/BC dates are not parsed correctly when coming from the JSON API #54

Open
noinkling opened this issue Mar 27, 2019 · 1 comment

Comments

@noinkling
Copy link
Contributor

noinkling commented Mar 27, 2019

Summary of the issue from https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON#time:

[in JSON] Years BCE are represented as negative numbers, using the historical numbering, in which year 0 is undefined, and the year 1 BCE is represented as -0001, the year 44 BCE is represented as -0044, etc., like XSD 1.0 (ISO 8601:1988) does. In contrast, the RDF mapping relies on XSD 1.1 (ISO 8601:2004) dates that use the proleptic Gregorian calendar and astronomical year numbering, where the year 1 BCE is represented as +0000 and the year 44 BCE is represented as -0043.

This can be confirmed with the following examples:

Q25299

"Point in time" (P585) value is shown as 1 BCE.

JSON snippet:

  "property": "P585",
  "datavalue": {
    "value": {
      "time": "-0001-01-01T00:00:00Z",

RDF TTL snippet:

wdt:P585 "0000-01-01T00:00:00Z"^^xsd:dateTime ;

Q25298 (2 BC)

JSON:

"time": "-0002-01-01T00:00:00Z"

TTL:

wdt:P585 "-0001-01-01T00:00:00Z"^^xsd:dateTime ;

JavaScript behaviour

The ES spec (since ES5) gives these specific examples:

-283457-03-21T15:00:59.008Z 283458 B.C.
-000001-01-01T00:00:00Z 2 B.C.
+000000-01-01T00:00:00Z 1 B.C.
+000001-01-01T00:00:00Z 1 A.D.

This means that JS follows the 2004 version of the ISO spec, and therefore matches the RDF serialization, but not the JSON.

In order to fix the time converter functions when parsing JSON-originating time values, 1 year needs to be added/subtracted (depending on which way you look at it) to years that are negative, if we want them to be accurate.

However since the same functions can be useful for dates coming from SPARQL queries or another RDF source, there might need to be an extra option parameter to select between behaviours, or two sets of functions to make it clear.

@noinkling
Copy link
Contributor Author

Just to make things more confusing, here's a counter-example where both the JSON and the RDF values are the same (-2500000-01-01T00:00:00Z): https://www.wikidata.org/wiki/Q3273066

I assume this has something to do with the precision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants