From T75272:
A fault with the user interface input parser is that it does not allow the entry of dates that exist in the Julian calendar but not the Gregorian calendar, such as February 29, 1700.
Reason is that dates in this format are processed by the PhpDateTimeParser.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use YearMonthDayTimeParser in TimeParserFactory | mediawiki/extensions/Wikibase | master | +22 -7 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T87764 Bugs related to time datatype (tracking) | |||
| Open | None | T98194 [Bug] Date parser does not allow February 29, 1700 (Julian) |
The relevant YearMonthDayTimeParser (see https://github.com/DataValues/Time/blob/master/src/ValueParsers/YearMonthDayTimeParser.php) that could fix this and quite a lot similar issues is already merged and released for a while now. It's just not used in Wikibase repo.
I notice this course calls eraParser. EraParser (see https://github.com/DataValues/Time/blob/master/src/ValueParsers/EraParser.php) appears to recognize years that contain + as CE, - as BCE, and several variations of the suffix as the appropriate era (CE, AD, Anno Domini, BCE, Before Christ, etc.) But I was unable to figure out what EraParser will do if the year is 0.
Change 240714 had a related patch set uploaded (by Jonas Kress (WMDE)):
[WIP] Use YearMonthDayTimeParser in TimeParserFactory
Unfortunately the YearMonthDayTimeParser is not fixing the problem. Do you have an idea @thiemowmde ?
1700-02-29 works BTW!
"1700-02-29" is "ISO-like" and parsed by IsoTimestampParser.
YearMonthDayTimeParser is currently not able to parse localized month names. This is by design. It can parse everything that contains three numbers, e.g. "29.2.1700", "02/29/1700" and so on. These two test cases should be added to https://gerrit.wikimedia.org/r/240714.
In https://github.com/DataValues/Time/pull/93 I'm exploring the idea to make YearMonthDayTimeParser aware of localized month names, but I'm not sure if this is the right thing to do. I need time to collect test cases.
As hinted in T98194#1684440 the original task description is still valid: When entering "February 29, 1700" our set of date parsers wrongly turn this into "1 March 1700". This ticket was in the previous sprint because of numeric inputs like "29.2.1700" and "02/29/1700", which are now allowed. We did not picked it up in the current sprint (it's only in the proposals column).