Last modified: 2014-10-17 10:03:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73956, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71956 - Parsing errors around year 0
Parsing errors around year 0
Status: RESOLVED DUPLICATE of bug 67604
Product: MediaWiki extensions
Classification: Unclassified
WikidataClient (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Wikidata bugs
u=dev c=backend p=0
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-11 15:07 UTC by Maarten Dammers
Modified: 2014-10-17 10:03 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Maarten Dammers 2014-10-11 15:07:55 UTC
Year 0 is a bit of an odd beast, see https://en.wikipedia.org/wiki/0_%28year%29

The parsing seems to go wrong in different cases:
* 0 with precision year gives 0
* 0 with precision decade or larger gives +00000000000-01-01T00:00:00Z
* 1+ with precision year works
* 1-4 with precision decade gives +00000000004-01-01T00:00:00Z
* 1-49 with precision century gives +00000000049-01-01T00:00:00Z
* 1-499 with precision millenium gives +00000000499-01-01T00:00:00Z
* etc

See https://www.wikidata.org/wiki/Q5959 for an example. It's impossible to add the birth date now without causing a parse error on Wikipedia.
Comment 1 Thiemo Mättig 2014-10-13 14:21:44 UTC
https://github.com/wmde/DataValuesJavascript/pull/49 is related to this (and several other report) but not an actual fix for the issue reported.

To be honest I don't understand the issue. You are talking about "parsing errors" but the examples you gave just parse fine without an error. Unfortunately you don't explain what you expect.
Comment 2 Maarten Dammers 2014-10-14 16:31:17 UTC
(In reply to Thiemo Mättig from comment #1)
> https://github.com/wmde/DataValuesJavascript/pull/49 is related to this (and
> several other report) but not an actual fix for the issue reported.
> 
> To be honest I don't understand the issue. You are talking about "parsing
> errors" but the examples you gave just parse fine without an error.
> Unfortunately you don't explain what you expect.

On connected wiki's it gives parsing errors, I already got a angry Russian user on my talk page.

If you access the property you get junk like "+00000000005-01-01T00:00:00Z".
Comment 3 tobias.gritschacher 2014-10-14 16:39:20 UTC
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=67604
Might be the same topic.
Comment 4 tobias.gritschacher 2014-10-14 16:43:40 UTC
And here is the bug to the conceptional issue that leads (among others) to the concrete problem described above.
https://bugzilla.wikimedia.org/show_bug.cgi?id=71289
Comment 5 Thiemo Mättig 2014-10-14 18:10:49 UTC
(In reply to Maarten Dammers from comment #2)
> On connected wiki's it gives parsing errors [...] junk like
> "+00000000005-01-01T00:00:00Z".

Again, what "parsing error"? Can you please give an example URL or steps to reproduce or the expected output or copy and paste the error message? An ISO date is neither "junk" nor a parsing error. The fact that you see an ISO date is the result of the fallback in the formatter as described in bug 67604.

I would love to tackle this but based on that few information I barely can.
Comment 6 Gerrit Notification Bot 2014-10-14 18:51:09 UTC
Change 166622 had a related patch set uploaded by Thiemo Mättig (WMDE):
Display full year if precision is to high

https://gerrit.wikimedia.org/r/166622
Comment 7 Thiemo Mättig 2014-10-14 18:53:16 UTC

*** This bug has been marked as a duplicate of bug 67604 ***
Comment 8 Gerrit Notification Bot 2014-10-17 10:03:02 UTC
Change 166622 merged by jenkins-bot:
Display full year if precision is to high

https://gerrit.wikimedia.org/r/166622

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links