Steps to reproduce:
Expected results:
Dates are formatted like "1983-06-13", noting that is the precision of the data
Actual results:
Dates having leading zeros and include milliseconds, like "+00000001983-06-13T00:00:00Z"
Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64084
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T87764 Bugs related to time datatype (tracking) | |||
| Resolved | thiemowmde | T62999 ISO date format has leading and trailing zeros |
Can't riproduce on that page, but Ladsgroup just linked a diff where the date is shown as +00000000795-00-00T00:00:00Z (even with standard preference).
Same issue?
https://www.wikidata.org/w/index.php?title=Q4119465&diff=123932128&oldid=123931985
http://lists.wikimedia.org/pipermail/wikidata-l/2014-April/003768.html
(In reply to Nemo from comment #1)
Can't riproduce on that page
When I try to reproduce, I see "date of birth: 30 May 1941" - my ISO 8601 date preference is now being ignored.
but Ladsgroup just linked a diff where the date is shown
as +00000000795-00-00T00:00:00Z (even with standard preference).
..
Same issue?
That is the same problematic output. ISO dates for the Gregorian year range 1583-9999 are tightly regulated by the spec, and should have four digits _only_ for the year, with the '+' prefix being unnecessary and probably even non-conformant. All other year values are not valid without a published specification from the sender.
Also, day precision with timezone precision is best formatted as '1941-05-30Z' (I vaguely also recall seeing '1941-05-30TZ' recommended, but I cant find that now). Including lots of zeros for the time adds ambiguity to the receivers ability to understand the ISO date.
Based on listening to devs chatting, the Wikibase falls back to ISO formatting when it cant localise the format.
Part of the issue is that diffs are cached. They must not depend on user settings. IIRC we set them up to be cached per language (would be bad to mix languages in the cache), but things like date format preferences really shouldn't go in there. Or we have to disable caching.
I guess we should have a separate bug for that. The caching issue is separate from the formatting issue (exposing the canonical "padded" for of the time string).
The issue described in this ticket is solved for some weeks now. Extra leading zeros (more than 4) are not stored any more. Additionally diffs don't show the time any more if it's meaningless.
We would like to support the users time format setting, but this is currently not possible because we must guarantee that all formats can also be parsed, which is not that easy (think of MDY vs. DMY ordered dates). This is also tracked in other tickets.