Last modified: 2014-05-01 11:06:18 UTC
Steps to reproduce: 1. Set ISO dates in the user prefs on Wikidata 2. Go to https://www.wikidata.org/wiki/Q6396063 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"
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).
