thiemowmde added a comment. As far as I understand the actual issue here is not that the format allows 2015-00-00 with month and day set to zero, but:
1. Naive string comparison fails for TimeValues that are "identical" from a users perspective. I do not think this is an issue we can ever fix with anything we do. It will always be possible to express the same thing with different values. For example, "2015-01-15T00:00:00, precision=DAY, after=1" and "2015-01-15T00:00:00, precision=HOUR, after=24" will be logically the same but different internally. Or there can be two timestamps in Gregorian and Julian describing the same thing but being different internally because of the calendar model. And so on. Naive string comparison is doing it wrong and can not be fixed by disallowing month and day being "00". 2. Some parser functions are build on top of PHP's date parsing and turn "2015-00-00" into 2014-12-30. I hope most people agree with me that this is broken and should be fixed in PHP, but probably can't because it always was like that and people started building apps on top of this broken behavior and will complain if it changes. However, the solution is pretty simple: when the precision is YEAR, do not use these parser functions but instead just split the year of the timestamp and show it as it is. I really, really do not think that a bug in PHP's date parser should motivate a workaround in the contents of the knowledge base we are building. I suggest to change the tickets title so it turns into something we can act on, or to close it. TASK DETAIL https://phabricator.wikimedia.org/T107870 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde Cc: daniel, Magnus, Ricordisamoa, thiemowmde, hoo, Lokal_Profil, Aklapper, Wikidata-bugs, aude _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
