-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix regex for time value #512
Conversation
Hello @eloiferrer , Can you share your Mediawiki and Wikibase version and the, if your wikibase is public, an item with a claim like this? Thank you, |
Hi, We are using Mediawiki 1.39.0-wmf.22, but I cannot yet point you to a public item using this format, although it does work for me locally. According to the examples shown here (https://www.wikidata.org/wiki/Help:Dates#Precision) this should be possible, so I am confused about the Malformed Input error. The item https://www.wikidata.org/wiki/Q301, for instance, has a date of birth equal to +1541-00-00T00:00:00Z. When I try to input +2023-00-00T00:00:00Z on test.wikidata.org with 'Date of birth' or 'Publication Date' I don't get an error. Maybe the Malformed Input refers only to the specific property you are using, or to some contradiction with the precision parameter? |
After more tests, you need to add the correction precision if you omit the day or the month. (Wikibase web UI do this automatically) I'll try to add more logic into the test. |
What do you think about the latest commits? |
I think it definitely works and I can work with that. But since the precision is implicit in the format, I think it would be better to add the logic that directly derives the right precision when the pattern is matched (if no precision is given by the user). Basically to avoid having to explicitly introduce the precision everytime that it is not days, as by default. I mean, if no precision is given by the user but match(YYYY-MM-00T00:00:00Z), then precision = months, if match(YYYY-00-00T00:00:00Z) = years, etc. And only if there is no match, then assume a default precision of days, and raise the error if necessary (i.e. if the user really enters a wrong format or contradictory format and precision parameters). That would probably require setting first the default value for precision to None, and assigning it to WikibaseDatePrecision.DAY only if necessary inside set_value. But maybe there is a reason not to do that. In any case, it otherwise seems redundant that every user will have to first check they are introducing the right precision for a given format that is not days. |
Hi @LeMyst, I've implemented what I mean, but if this is too much of a change we can just revert the changes and merge your version. |
Thank you for this PR @eloiferrer ;) |
Time values with month = 00 or day = 00 (e.g. +2023-00-00T00:00:00Z, +2023-02-00T00:00:00Z) are also allowed and should not raise an error.