| agray created this task. agray added a project: Wikidata. Herald added a subscriber: Aklapper. |
When information is entered into a property field with 'time' datatype (eg start time, P580), the system makes an attempt to parse what's been entered and convert it into a coherent standardised date, then shows this to the user so they can change it if it's been misinterpreted.
Dates entered as xx-yy-zzzz are challenging for the parser, as they might be intended as MM-DD or DD-MM. The algorithm seems to check to see if xx or yy is greater than 12, and if so, treat that as the month day element; but if both are twelve or less, then it's still ambiguous. At this point, the parser gets a bit strange.
Dates written as 9 7 2017, 9.7.2017, 9,7,2017, or 9-7-2017 - with the digits separated by spaces, dots, commas, or hyphens - are interpreted as 9 July - ie DD-MM-YYYY.
Dates written as 9/7/2017 - with the digits separated by forward slashes - are interpreted as September 7, ie MM-DD-YYYY.
There does not seem to be any clear reason for this inconsistency, and it's a bit confusing for end users. It looks like the intended outcome is for dates to default to DD-MM-YYYY unless obviously MM-DD, but this doesn't seem to be reliably implemented.
(As an aside, most other punctuation causes an invalid date - the one unusual exception is |, where 9|7|2017 is parsed as the year "9" - apparently everything after the first pipe is ignored. But as this is an incredibly odd way to represent dates, it probably doesn't matter...)
Cc: Aklapper, agray, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
