Currently, entering "20. century" will result in the timestamp +00000002000-01-01T00:00:00Z with the precision set to "century"[1].
Similarly, entering "3. millennium" will result in the timestamp +00000003000-01-01T00:00:00Z with the precision set to "millennium"[2].
This is clearly wrong: the 20th century is the one from the start of 1901 to the end of 2000,
the 3rd millennium is the one from the start of 2001 to the end of 3000.
So, "20. century" should result in the timestamp +00000001901-01-01T00:00:00Z, with precision "century" (and before=0 and after=1 [3]), to accurately represent the century between the start of 2001 and the end of 2100.
Similarly, "3. millennium" should result in the timestamp +00000002001-01-01T00:00:00Z.
An alternative fix would be to set the before=1 and after=0 - but then, the timestamp would still be off by a year (the 20th century ended 2000-12-31T23:59:59, not 2000-01-01T00:00:00).
When fixing this, we should also investigate how many century/millennium dates we already have in the database. Many of these are likely to have the wrong timestamp.
[1] https://www.wikidata.org/w/index.php?title=Q4115189&diff=160572560&oldid=160505889
[2] https://www.wikidata.org/w/index.php?title=Q4115189&diff=160674691&oldid=160586967
[3] we actually set both before and after to 0 at the moment. That's bug 65253. Per default, after should be 1, otherwise the precision would be meaningless (as before and after are factors to be applied to the precision).
Version: unspecified
Severity: critical
Whiteboard: u=dev c=backend p=0