Help:Dates

Wikidata offers a series of properties with datatype time, which allow storage of basic information defining single point in time. Time datatype can be further expanded with custom qualifiers to allow great range of possible time expressions. Adding and querying dates may seem simple, but available precision and changing calendars add complexity.

See also mw:Wikibase/DataModel/JSON#time

Page Special:ListDatatypes describes time datatype as

Literal data field for a point in time. Given as a date and time with some precision and boundaries. The time is saved internally in the specified calendar model.

• time – explicit value for point in time, represented as a timestamp resembling ISO 8601, e.g. +2013-01-01T00:00:00Z. The year is always signed and padded to have between 4 and 16 digits.
• timezone – explicit value as a signed integer. Timezone information as an offset from UTC in minutes.
• before – explicit integer value for how many units after the given time it could be. The unit is given by the precision.
• after – explicit integer value for how many units before the given time it could be. The unit is given by the precision.
• precision – explicit value encoded in a shortint. The numbers have the following meaning: 0 - billion years, 1 - hundred million years, ..., 6 - millennium, 7 - century, 8 - decade, 9 - year, 10 - month, 11 - day, 12 - hour, 13 - minute, 14 - second.
• calendarmodel – explicit value given as a URI. It identifies the calendar model of the timestamp.

That is an accurate description of the saved structure; however, much of it is not being used at the moment:

• time field can not be saved with precision higher than a "day".
• We do not use before and after fields and use qualifiers instead to indicate time period.
• timezone is also not used the encoding (Z) suggest UTC timezone (the date in London), but general practice on Wikidata is to save dates as reported in literature, which usually means in local timezone.
• calendar – explicit value defining calendar model. Currently two calendar models are supported: proleptic Gregorian calendar (Q1985727) and proleptic Julian calendar (Q1985786)

For example, the actual data structure of Adam Mickiewicz (Q79822)start time (P580) is

          ["P580"] = table {
            table {
              ["datatype"] = "time",
              ["datavalue"] = table {
                ["type"] = "time",
                ["value"] = table {
                  ["after"] = 0,
                  ["before"] = 0,
                  ["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
                  ["precision"] = 9,
                  ["time"] = "+1838-01-01T00:00:00Z",
                  ["timezone"] = 0,
                },
              },
              ["hash"] = "1438e02cdfc7ff91f7e722fbbf09f5ba5dba259b",
              ["property"] = "P580",
              ["snaktype"] = "value",
            },
          }

Below is a table with example time strings for several precision values. The strings can be accessed using Lua commands and are also used by QuickStatements (Q20084080)   .

The user interface interprets precision 7 (100 years) and 6 (1,000 years) using strict historical definitions of those terms, which starts with year ending with 01 and ends with year ending with 00. That might be counterintuitive to some people. When using the precision 7 or 6 it is safer to avoid years with the last digits 00. One option is to use the earliest year that avoids the problem, such as 2001 for the 3rd millennium. Another option is to use a date near the midpoint of the range, such as 1950 for the 20th century.

Precisions higher than 11 (day) are not supported as of 2021. These would be:

There is a feature request to make this possible at phab:T57755.

Due to glitches in the api, a few values with such precision existed in Wikidata.

A workaround is to use the qualifier located in time zone (P421) together with the qualifier refine date (P4241) (described below) and values such as the items 11 PM (Q44529925), 23:00 (Q55812301) or 23:00:00 (Q95135875). Note the difference in precision of these items: hour, minute, second. A list of minute-precision items is at lists/time of the day.

There was also proposal for a dedicated qualifier (Property proposal/local time).

Properties opening time (P8626) and closing time (P8627) use time items as values as well. There were also some discussions to support one or the other string-based formats for such ranges.

Qualifiers can be used to explain or customize dates that cannot be fully represented by the date model above. The precision of the date being qualified should have a precision that encompasses the range described by the qualifiers, or be set to "unknown value" (["snaktype"] = "somevalue"); you can choose an alternative value type by clicking the icon before the input box.

• earliest date (P1319) and/or latest date (P1326) - earliest and latest possible time that some event could have occurred.
• start time (P580) and/or end time (P582) - beginning and end of some period of time.
• sourcing circumstances (P1480) qualification of the accuracy of a statement. Allowed values: circa (Q5727902), near (Q21818619), presumably (Q18122778), disputed (Q18912752), etc.
• refine date (P4241) qualifier to narrow down the precision of a date. Allowed values:

• parts, like beginning of (Q40719727), middle of (Q40719748) and end of (Q40719766)
• halves, usually of a year, decade or century first half (Q40719687) and second half (Q40719707)
• quarters, usually of a century: first quarter (Q40690303), second quarter (Q40719649), third quarter (Q40719662) and fourth quarter (Q40719674)
• seasons, observed in northern and southern hemisphere

• winter (northern hemisphere) (Q40720553), spring (northern hemisphere) (Q40720559), summer (northern hemisphere) (Q40720564), autumn (northern hemisphere) (Q40720568)
• winter (southern hemisphere) (Q40720946), spring (southern hemisphere) (Q40720950), summer (southern hemisphere) (Q40720953), autumn (southern hemisphere) (Q40720956)

Example dates and how to save them

Time qualifiers can also be used to provide more information about almost any statement. Those would be:

• start time (P580) and end time (P582) for describing period of time some statement was true
• point in time (P585) for describing point of time some statement was true

Full list of time properties can be found at Special:ListProperties/time.

Each person should have some properties related to lifespan:

Time properties are also used to record significant dates related to artworks, books, buildings and other objects:

For yearly recurring events there is day in year for periodic occurrence (P837), a special example is birthday (P3150). Help:Easter related dates helps with finding items for recurring days defined by their distance to Easter.

When a date in 2024 is entered, e.g. 2024-11-14, the calendar model is set by default to proleptic Gregorian calendar (Q1985727).

For current dates, this works fine.

For earlier dates, the applicable calendar should be determined:

• The Gregorian calendar was first introduced in 1582 replacing the Julian calendar.
• The last countries to convert from the Julian to the Gregorian calendar did so in the 1920s. → w:Adoption of the Gregorian calendar.

Depending on the country and the source at hand, the applicable calendar has to be determined and entered.

• On manual entry, the software defaults to proleptic Gregorian calendar (Q1985727) from 1583.
• Dates before are considered by default as proleptic Julian calendar (Q1985786).
• In the advanced options, the calendar model can be changed.

If it can't be determined if the date is in one or the other calendar, that date should be entered in the default calendar with the qualifier sourcing circumstances (P1480) = unspecified calendar (Q18195782).

Some countries did use or still use other calendars. None of these are supported. Dates need to be converted to Julian or Gregorian.

In quite a few cases the exact date of an event (like a date of birth) is not known. We have several approaches depending on how the source documents it.

Manually update chart WDQS | PetScan | TABernacle | Find images | Recent changes Graphs are temporarily unavailable due to technical issues. End of automatically generated list.

Precision

The first approach is to change the precision. For example when the source says 1620s:

1. Add a date claim
2. Enter a year (for example 1625)
3. Click "advanced adjustments"
4. Change the precision to something suitable (for example a decade)
5. Add the source
6. Save the statement

Qualifiers for earliest/latest

The first approach can be expanded if you know a before and/or after date. For example when the source says before 1625:

1. Add the statement as above, but don't save it yet
2. Add a qualifier latest date (P1326) and/or earliest date (P1319) with the date
3. Save the statement

Qualifier for circa

The second approach is suitable if the source says around a certain date or year. For example "around 1622":

1. Add a date claim with a certain date
2. Enter the year (for example 1622)
3. Add qualifier sourcing circumstances (P1480) -> circa (Q5727902)
4. Add the source
5. Save the statement

• Years BC should be entered as is.

Sample: Year 458 BC on Q309637#P39 is entered as "458 BCE" and appears as "458 BCE".

• For RDF export (e.g. on Wikidata Query Service) the following applies: "The dates follow XSD 1.1 standard, i.e. 1 BCE is year 0."^[1]. Year "0" is also exported as year 0, but only if it is Julian calendar, because non-Gregorian dates are passed through as is. Year 0 Gregorian is invalid in the database would not be exported. Year 2 BCE, as -1.

Sample: Year 458 BC on https://www.wikidata.org/wiki/Special:EntityData/Q309637.rdf appears as "<pq:P585 rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">-0457-01-01T00:00:00Z</pq:P585>". The same is visible on the below SPARQL query.

SELECT *
{
	VALUES ?item { wd:Q309637 }
  	?item p:P39 ?p1 . ?p1 pqv:P585 ?p3 . ?p3 ?p4 ?p5
}
LIMIT 100

• For RDF export (e.g. on Wikidata Query Service), dates BC (as any dates) are converted to Gregorian dates.

Sample: 27 November 8 BCE appears as "-0007-11-25T00:00:00Z"

• For JSON export the format is inspired by XSD 1.0 and ISO 8601:1988. The year 0 is undefined, 1 BCE is exported as -0001, 2 BCE is exported as -0002, etc.

• Sample: Year 458 BC on https://www.wikidata.org/wiki/Special:EntityData/Q309637.json appears as "{"time":"-0458-00-00T00:00:00Z","timezone":0,"before":0,"after":0,"precision":9,"calendarmodel":"http://www.wikidata.org/entity/Q1985786"}"

Examples of syntax:

SELECT ?item ?itemLabel ?time
WHERE
{
  ?item wdt:P585 ?time.
  FILTER (   YEAR(?time) > 1450 && YEAR(?time) < 1454  ).
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
}

SELECT ?item ?itemLabel ?time
WHERE
{
  ?item wdt:P585 ?time.
  FILTER ((?time > "1452-01-01"^^xsd:dateTime) && (?time < "1452-12-31"^^xsd:dateTime)).
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
}

SELECT ?item ?itemLabel
WHERE
{
  ?item wdt:P585 "+1789-07-14T00:00:00Z"^^xsd:dateTime.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
}

SELECT ?item ?itemLabel ?time ?precision
WHERE
{
  VALUES ?precision { 10 11 }#10 = month precision, 11 = day precision
  ?item p:P569/psv:P569 [wikibase:timePrecision ?precision; wikibase:timeValue ?time].
  FILTER (   YEAR(?time) = 1700 ).
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
} 
LIMIT 10

Some dates from date of birth (P569):

as of 2022-02-02

Query

A January 1 date of birth (P569) can occur for several reasons:

• (A) a person was born on January 1
• (B) a person's birth was registered as being on January 1
• (C) a person's exact date of birth is unknown, but was officially registered with the year and "January 1"
• (D) a database stores year precision dates with "January 1"
• (E) a conversion between some database and Wikidata led to the year of birth added as January 1 of that year.

Wikidata would generally include (A), (B), (C) with the appropriate reference and rank. (D) would generally be stored with deprecated rank or year precision. (E) should be corrected by changing the date precision to year.

Similar problems can be found with other dates, e.g. date of death (P570).

See Phab:T87764 (Bugs related to time datatype (tracking))

• In 2015, the format for dates was changed. Julian dates entered before are likely to be off a few days.
• Some dates may have year precision, but have been entered as day precision
• The documentation indicates the time zone exists, but the only time zone that can be entered is an offset of 0 from w:universal time. Since it is impossible to capture the time zone of the source, most of the dates in Wikipedia are, strictly speaking, false.
• See Phab:T95553. The user interface accepts and presents dates with precision 7 (100 years) strangely, enticing editors to enter incorrect dates.

• JSON data model
• RDF Dump Format

1. ↑ mw:Wikibase/Indexing/RDF_Dump_Format#Time