Page MenuHomePhabricator

Make low year numbers less ambiguous
Closed, ResolvedPublic5 Estimated Story Points


Main components:

  • WikibaseLib

User story:
As an editor, I want to have a clearer indication if a number in a date is a year or a day in order to correctly enter my data.

Right now it is not obvious if "January 1" is the first of January in an arbitrary year or the month January in the year 1. We need to make this more obvious.



image.png (246×1 px, 30 KB)

GIVEN a date between -99 and 99
WHEN displaying it in the statement view
OR WHEN displaying it in client wikis with the default formatting (e.g. {{#statements:}} parser function)
THEN we add BCE/CE at the end of the data

Acceptance criteria:

  • For years below 100 we add BCE/CE in the formatted value
  • The new formatting of the values can also be parsed! (roundtrip)


  • We do this regardless of the precision of the date.
  • This is already happening for BCE dates.
  • We want this for both Wikidata and Wikibase.

Original report:
In English, you can write the 1st of January as "January 1". If you enter that into a date field on Wikidata, it will accept it as valid and there is no indication that it has actually interpreted the "1" as a year. If the user intended the day, since it looks correct, they will save the value, completely unaware that it has been interpreted as something entirely different.

I made that mistake and I was able to find examples of it happening to other people, e.g., and

One solution would be to always indicate low year numbers (any one or two digit ones, maybe even three digit ones) using eras, so that it's clearer that the year is meant, e.g. says "AD 7", says "11 n. Chr.".

Event Timeline

Nikki raised the priority of this task from to Needs Triage.
Nikki updated the task description. (Show Details)
Nikki added a project: Wikidata.
Nikki added a subscriber: Nikki.
thiemowmde triaged this task as Lowest priority.Jul 15 2015, 3:37 AM
thiemowmde added a project: DataValues.
thiemowmde set Security to None.
thiemowmde added a subscriber: thiemowmde.

Change 236010 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Avoid exponential years in MwTimeIsoFormatter

Change 248895 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Always output 4-digit years in dates like "1 January 2"

Jonas renamed this task from Low year numbers can be confused with days of the month to [Bug] Low year numbers can be confused with days of the month.Nov 2 2015, 10:22 AM

Discussed with @Lydia_Pintscher this morning.

  • "1 February 2" is confusing. Is it the year 1 or 2?
  • "February 2" is confusing. Is this February the 2nd?
  • "1 February 99" can be confused with the year 1999.
  • Extending the format to "1 February 2 AC" does not help much, in my opinion. This adds confusion because now I need to know what "AC" means and why it is there. It does not really solve the confusion which number is the year. You need to know that "2 AC" is meant to be the year, but is this really always the case, in all languages?
  • English Wikipedia sometimes tries to solve this problem with "1 February AC 2".
  • The problem is less prominent in German, because we already format this as "1. Februar 2".
  • In tables this is usually not a problem, because you compare rows and understand where the year is in "28 March 1700" and "1 February 2" and so on.
  • In text this is usually solved by writing "year 2".
  • {{#time:Y|0002-02-01}} both requires the input to be padded with zeros (otherwise it will wrongly interpret the years 0 to 69 as 2000 to 2069 and 70 to 99 as 1970 to 1999) and pads the output with zeros. We could argue that we want to be consistent with that.
  • When a user combines {{#time:Y|{{#property:…}}}} this will just work fine in most cases, even if it's not intended to be used like this. If the property parser function outputs "1 February 1999", {{#time:Y|1 February 1999}} outputs "1999". But {{#time:Y|1 February 99}} outputs "1999" and {{#time:Y|1 February 2}}outputs "2002". All this confusion can totally be avoided by adding leading zeros.
  • A year alone should never be padded with zeros. We think that "0002" will cause more confusion and friction than it is helpful.
  • A possible way forward is to start working on the possibility to specify a date format along with the {{#property:…}} parser function. Or make it possible to combine {{#time:…|{{#property:…}}}} without the issue described above. This allows for individual case-by-case solutions when they are needed.
  • Note that our current way of formatting years as straight numbers with no leading zeros is not backed by an existing {{#time:…}} format string. Only "y" and "Y" exist, both always output the year with a fixed length of 2 or 4 characters. So the year 2 becomes "02" or "0002", but there is no way to output "2". This may need a new format string.

Decision made in today's story time: We will add BCE/CE for years <= 99.

Change 248895 abandoned by Thiemo Mättig (WMDE):
Always output 4-digit years in dates like "1 January 2"


Possible solution here
And they should probably be merged

Lydia_Pintscher raised the priority of this task from Lowest to Needs Triage.Sun, Aug 29, 5:11 PM
Addshore set the point value for this task to 5.Wed, Sep 15, 10:35 AM
Manuel renamed this task from [Bug] Low year numbers can be confused with days of the month to Make low year numbers less ambiguous .Wed, Sep 15, 11:06 AM
Manuel updated the task description. (Show Details)

Change 721862 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Format low year numbers with CE for disambiguation

Change 721862 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Format low year numbers with CE for disambiguation