Documentation

Difference with “date of birth (P569)” within range [-1, 150]: the difference with property “date of birth (P569)” should be in the range from “-1” to “150”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Zaro Aga (Q148028), Thomas Parr (Q657399), Shirali Muslumov (Q2349607), Mahmud Eyvazov (Q4529980), Kyle Reese (Q592358), Li Ching-Yuen (Q304690)
List of violations of this constraint: Database reports/Constraint violations/P570#Diff within range

Type “human (Q5), fictional character (Q95074), organism (Q7239), person (Q215627), legendary figure (Q13002315), group of humans (Q16334295), human whose existence is disputed (Q21070568)”: item must contain property “instance of (P31)” with classes “human (Q5), fictional character (Q95074), organism (Q7239), person (Q215627), legendary figure (Q13002315), group of humans (Q16334295), human whose existence is disputed (Q21070568)” or their subclasses (defined using subclass of (P279)). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#Type Q5, Q95074, Q7239, Q215627, Q13002315, Q16334295, Q21070568, SPARQL

Qualifiers “sourcing circumstances (P1480), earliest date (P1319), latest date (P1326), reason for preferred rank (P7452), reason for deprecated rank (P2241), refine date (P4241), determination method or standard (P459), age of subject at event (P3629), statement is subject of (P805), nature of statement (P5102), statement supported by (P3680), time index (P4895), located in time zone (P421), announcement date (P6949), object named as (P1932), statement is regarded as spoiler for (P7528), applies to work (P10663), object of statement has role (P3831), statement disputed by (P1310), instance of (P31), image of grave (P1442), inscription (P1684), cause of death (P509)”: this property should be used only with the listed qualifiers. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#allowed qualifiers, SPARQL

Conflicts with “instance of (P31): Wikimedia permanent duplicate item (Q21286738), Wikimedia disambiguation page (Q4167410), Wikimedia list article (Q13406463)”: this property must not be used with the listed properties and values. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#Conflicts with P31, SPARQL

Range from “-3200000-00-00T00:00:00Z” to “now”: values should be in the range from “-3200000-00-00T00:00:00Z” to “now”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: T'Kuvma (Q48078634), Susan Calvin (Q1073739), Hoban Washburne (Q16499545), Lexa (Q23023325), Great Harlock (Q3115952), Snake Plissken (Q3487121), John Connor (Q376577), Philippa Georgiou (Q43740811), Hugh Culber (Q48032489), James T. Kirk (Q16311), Martia (Q53858092), X-24 (Q50805198), Prophet of Truth (Q55685702), Kiva Andru (Q61890789), Dr. Mid-Nite (Q89593181), Tony Stark (Q23894967), Jhil (Q64141306), Zlatko Andronikov (Q109940640)
List of violations of this constraint: Database reports/Constraint violations/P570#Range

Single best value: this property generally contains a single value. If there are several, one would have preferred rank (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#single best value, SPARQL

Citation needed: the property must have at least one reference (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#citation needed

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#Entity types

Scope is as main value (Q54828448), as qualifier (Q54828449), as reference (Q54828450): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P570#Scope, SPARQL

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Wrong calendar
People died before 1582 whose death date is registered using proleptic Gregorian calendar (Q1985727) instead of proleptic Julian calendar (Q1985786). (Help)
Violations query:

SELECT ?item WHERE { ?item p:P570/psv:P570 ?datevalue . ?datevalue wikibase:timeValue ?date .            FILTER(?date < "+1582-10-15T00:00:00Z"^^xsd:dateTime) ?datevalue wikibase:timePrecision ?dateprecision .  FILTER(?dateprecision > 9) ?datevalue wikibase:timeCalendarModel wd:Q1985727 . }   LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P570#Wrong calendar

Probably died
People born before the year 1900, but no date of death (P570) (Help)
Violations query:

SELECT DISTINCT ?item WHERE {   ?item p:P569 ?birthclaim .   MINUS { ?item p:P570 [] }   ?birthclaim ps:P569 ?birth .   FILTER(?birth < "+1900-00-15T00:00:00Z"^^xsd:dateTime) . } LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P570#Probably died

Items with P570 = "no value" (P31=Q5)
Most people are not immortal (Help)
Violations query: SELECT ?item WHERE { ?item p:P570/a wdno:P570; wdt:P31 wd:Q5 } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P570#Items with P570 = "no value" (P31=Q5)

Check horse longevity
(Help)
Violations query:

SELECT ?item ?itemLabel ?born ?died ?diff WHERE {   ?item wdt:P31 wd:Q726. # horses   ?item wdt:P569 ?born.   ?item wdt:P570 ?died.   BIND((?died - ?born)/365 AS ?diff)   FILTER (?diff > 62.945205479452056). } ORDER BY ?diff

List of this constraint violations: Database reports/Complex constraint violations/P570#Check horse longevity

Date must be before now
(Help)
Violations query:

SELECT ?item ?date {   ?item wdt:P570 ?date.   ?item wdt:P31 wd:Q5.   FILTER (NOW() < ?date)   FILTER (?date != "2001-01-01") }

List of this constraint violations: Database reports/Complex constraint violations/P570#Date must be before now

Inverted month/day on items with 2 dates
Items with 2 dates, day of the first date = month number of the second date, month of of first = day of the second. To fix, set on to preferred or deprecated rank (Help)
Violations query:

SELECT * {     ?item wdt:P570 ?d1 ; wdt:P570 ?d2 .     FILTER(            ?d1 != ?d2             && MONTH(?d1) = DAY(?d2)             && DAY(?d1) = MONTH(?d2)             && YEAR(?d1) = YEAR(?d2)             && DAY(?d1) != DAY(?d2)            ) } LIMIT 10

List of this constraint violations: Database reports/Complex constraint violations/P570#Inverted month/day on items with 2 dates

Died after 2100
(Help)
Violations query:

SELECT ?item ?date WHERE {   ?item wdt:P570 ?date.   FILTER ( ?date > "2100-04-20T00:00:00Z"^^xsd:dateTime )   FILTER NOT EXISTS { ?item p:P6262 [] }   FILTER NOT EXISTS { ?item p:P1441 [] }   FILTER NOT EXISTS { ?item p:P1080 [] } }

List of this constraint violations: Database reports/Complex constraint violations/P570#Died after 2100

Manually update chart

Graphs are temporarily unavailable due to technical issues.

This property is being used by:

he:תבנית:אישיות_תקשורת

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

This property is being used by:

he:תבנית:אישיות

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

This property is being used by:

he:תבנית:סופר

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Queries

people with dates of birth and death on January 1st (day precision dates)

Items used: human (Q5)

Properties used: instance of (P31)   , date of death (P570)   , date of birth (P569)

#title: people with dates of birth and death on January 1st (day precision dates)
SELECT ?item ?itemLabel ?itemDescription ?born ?died
{
  ?item p:P570 [ a wikibase:BestRank; psv:P570 [ wikibase:timeValue ?born; wikibase:timePrecision 11 ]] . 
  FILTER( MONTH(?born) = 1 && DAY(?born) = 1 ) 
  ?item p:P569 [ a wikibase:BestRank; psv:P569 [ wikibase:timeValue ?died; wikibase:timePrecision 11 ]] . 
  FILTER( MONTH(?died) = 1 && DAY(?died) = 1 ) 
  ?item wdt:P31 wd:Q5 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 1000

Try it!

Discussion

Keeping up to date

As one of the major uses of Wikidata is to keep Wikipedias up to to date, I thought it could be worth trying to organize things a bit. I found http://www.legacy.com/memorial-sites/2014/ that allows to keep watch of the recently dead. Could also do something like a "dead this week list that Wikipedias could consult ? --Zolo (talk) 09:28, 12 April 2014 (UTC)[reply]

Died "after 1110"

According to William Devereux, he died "after 1110". Is there a way to add it with date of death (P570) at William Devereux (Q8007795)? --- Jura 12:37, 17 May 2014 (UTC)[reply]

He died before 1210 for sure. May be to point date of death (P570) = 1160±50? --Infovarius (talk) 10:11, 23 May 2014 (UTC)[reply]

In the meantime, there is the property "floruit": I added that.

The article also mentions the he was likely dead a some point "During the time of Abbot William (1113 to 1130)". I tried to include this with the two other new properties: P1319 and P1326 --- Jura 16:52, 24 May 2014 (UTC)[reply]

Living people and no value

All people die at some point in time. Did we already had a discussion somewhere about adding no value to living people? We could be a bit more philosophical and add "unknown value" (everyone dies, we just don't know when), but that would make it harder to distinguish with people we do know they died, just not sure when. Multichill (talk) 19:52, 8 October 2014 (UTC)[reply]

I prefer to use "unknown value" for peoples with unknown death date only. "no value" is applicable for god and some other fictional characters maybe. I think it is better do not create this property for living peoples at all. If we will create this property, will we add place of death (P20)='no value', place of burial (P119)='no value', image of grave (P1442)='no value', cause of death (P509)='no value', manner of death (P1196)='no value', killed by (P157)='no value' to all living peoples too? — Ivan A. Krestinin (talk) 21:09, 8 October 2014 (UTC)[reply]

strong

Support--Oursana (talk) 22:24, 8 October 2014 (UTC)[reply]

"unknown value" seems indeed confusinhg, but we seem to need a way to say "this person is not dead this is why we do not provide a death date (equivalent to Category:Living people (Q5312304) for Wikipedia).

Even though it is conceptually shaky, I guess "no vaue" is the most practical solution. We could have a common sense guideline saying: "if someone is not dead (and has no definite, sourceable death forecasts), add "date of death: no value", do not add other properties like place of death, etc.". --Zolo (talk) 07:39, 9 October 2014 (UTC)[reply]

Oppose for living people this field shall stay untouched. It would be filled someday anyway. So far we have no difference in wikipedia infoboxes in "no value at all" and "empty value", and filling this field basing on categories is very very bad idea. Thus i see no reason to confuse data clients. -- Vlsergey (talk) 08:01, 9 October 2014 (UTC)[reply]

I was not suggesting to add it based on categories (though I do not see major issues doing that as a first step). My point was that these "not dead people" categories exist (I think partly articles about living people are more sensitive, and partly because it is a useful marker for maintenance), and if we want to have the same information on Wikidata, the simplest solution seems to go through "unknown values". Well admittedly, we can probably also do without adding anything and find other ways to check for missing death dates. --Zolo (talk) 14:18, 9 October 2014 (UTC)[reply]

The reason I brought this up here is because I talked with Daniel about this last weekend. I just want to see what according to you guys, the pro's and con's are. The mass adding would maybe be a next step, but let's just leave that part for later. Please don't make this a sliding scale argument. Introducing something like this only makes sense when we're ready for it and when it doesn't mean we'll create a huge backlog because the data isn't available.

The pro is that it's easier to track completeness. Every human should just have the property. Easy to do reports and fix things.

The con is maybe the extra work and that downstream (Wikipedia) will get confused.

Multichill (talk) 12:25, 11 October 2014 (UTC)[reply]

Albeit a little bit late, I am adding my comment as I could not work out if any conclusion was reached above and I have a vested interest in utilising birth and death dates. We should be working on the assumption that the person is alive unless we know otherwise. i.e. We do not add any death related properties until that person is > 125 years old or that we know for fact that they died. Only then we can use the "date of death = unknown" option.

If a date of death property is added to everyone "in anticipation", then we cannot distinguish those who are known to have died but we are just missing a date. Periglio (talk) 09:34, 24 January 2015 (UTC)[reply]

I think it´s a good idea to use "no value" for gods and/or fictional persons who don´t die (or can´t die). There will for sure be no value ever. For persons that are definitely not alive any more but the date of death is unknown it is good to use "unknown value" (e.g. birth date is before 1900 or has published works before 1920). Unknown value implies there is a value we don´t know today. There might be a yet unidentified source out there, that can provide the value some day. For living persons we should ommit the property at all.--Giftzwerg 88 (talk) 15:49, 24 January 2015 (UTC)[reply]

For living people, there is also floruit (P1317). It can include a date and a reference. --- Jura 20:05, 5 May 2015 (UTC)[reply]

@Periglio, Multichill, Giftzwerg 88: et al. Sorry to re-open this discussion two years after, but I found several item older than a century without date of death (P570). As I understand, the summary is:

People without date of death (P570), means "alive".
People with a date in date of death (P570), means "died".
People who is known that is died but in an uncertain date, should have "unknown value" as date of death (P570), until somebody knows it.
People whose date of death is unknown and born over 125 years ago, should have "unknown value" as date of death (P570), until somebody knows it.

If it is correct, we should decide what to do with the more than 10000 people born before 1880 and without date of death (P570). Does it make sense to run a bot to fill it ?. Thanks, Amadalvarez (talk) 20:21, 11 January 2018 (UTC)[reply]

@Amadalvarez: I try not to use "unknown", but to use a date with a high uncertainty. I'd rather not have a bot mass adding unknown. People can work on subsets like Wikidata:WikiProject sum of all paintings/Dead painters to reduce the backlog. Multichill (talk) 16:56, 12 January 2018 (UTC)[reply]

I'm not sure if much is gained by adding "unknown" to people that are obviously dead. It would be better to attempt to find actual dates and only when these are not available to insert a century or decade, plus "floruit". What would help is to focus on people aged 95 to 125 and attempt to determine when they were last known to be alive (or dead).
--- Jura 17:08, 12 January 2018 (UTC)[reply]

@Multichill, Jura1: In cawiki we determine "category: alive person" in function of P570. So, we have a lot of false positive. Personally, I agree with both of you: fill date of death with century because is a correct but imprecise information, but not a false info. My summary just tried to resumme the last entries of the discussion, but I'll follow your opinions. Thanks a lot. --Amadalvarez (talk) 17:53, 12 January 2018 (UTC)[reply]

@Amadalvarez: You should update the template to also check the date of birth. If you update your local Module:Wikidata from en:Module:Wikidata you can do {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|y}} to get the year of birth. Multichill (talk) 18:50, 12 January 2018 (UTC)[reply]

+1 --Marsupium (talk) 13:34, 13 January 2018 (UTC)[reply]

@Jura1: Of course our wikidata module handle P569, even calculate the age (P570-P569) taking care of diferents precissions between both properties. The question is not "What to do with the template to solve the problem". The question is: people without P570 are "pressumibly alive". Neither floruit (P1317) nor date of disappearance (P746) certify that person has died, except that some information is put in P570, either an "unknown" or a date with a lower precision date like century, either accompanied by sourcing circumstances (P1480) + presumably (Q18122778), second quarter (Q40719649), etc. second half (Q40719707) or earliest date (P1319) + flourit or reasonable date, for instance.. I started to fix the empty P570 with this kind of solutions after tried to find the real year. Until now, I found near 10% of real date inside the article or in its references for people of 19th century. Obviously, the people with date of birth expressed in centuries or milennium, I'll consider that have the same value for death's date. Thanks again. Amadalvarez (talk) 17:31, 14 January 2018 (UTC)[reply]

I agree with Jura in that nothing is gained by a bot. IMHO, unknown says "someone has done the research but came up with nothing" and left blank indicates someone needs to look it up. Anyone using the data would have the flexibility to handle these two scenarios as they require. Periglio (talk) 19:25, 12 January 2018 (UTC)[reply]
+1. Question aside: How do other databases handle this? --Marsupium (talk) 13:34, 13 January 2018 (UTC)[reply]
BTW, Wikidata:Database_reports/birthday_today/to_check has people born before 1917 where it would be good to check if they reached 100 or died. It was started as we kept getting people who disappeared at the end of WWII on Wikidata:Database reports/birthday today.
--- Jura 07:16, 14 January 2018 (UTC)[reply]

Dates available at Wikipedia

At frwiki, I added a maintenance category for P570: fr:Catégorie:P570 absent de Wikidata. Currently just one or two templates feed into that. --- Jura 10:42, 16 June 2015 (UTC)[reply]

Death during the night ?

Hello, I came across Jean-Yves Cozan (Q3170127) for who the sources say he is dead during the night between the 15th and 16th June, is there any way to code that in WD ? 20:22, 16 June 2015 (UTC)

Hi, data model have ability to describe this case. But current Wikidata core and editor implementation does not support required model features. — Ivan A. Krestinin (talk) 22:49, 16 June 2015 (UTC)[reply]

Declared dead

At Q3517088#P570, I added as qualifier declared dead (Q21091870). Not sure if the date should be in 1984 or 2004. --- Jura 11:56, 12 October 2015 (UTC)[reply]

@Jura1: I don't know, but I think I would personally use sourcing circumstances (P1480) as the property of the qualifier for that case... -- Agabi10 (talk) 18:28, 12 October 2015 (UTC)[reply]

Not sure about the use of that qualifier. It might make sense on the date in 1984.

The problem is that it's a theoretical date. Here is another one: Q5577585#P570.--- Jura 16:37, 14 October 2015 (UTC)[reply]

Value for reason for deprecated rank (P2241)

person found to be alive (Q21124171) can be used. --- Jura 11:48, 16 October 2015 (UTC)[reply]

or: only disappearence confimed (Q37627247)
--- Jura 14:22, 21 August 2017 (UTC)[reply]

BCE / BC

This (and I guess other dates) support the BCE format e.g. https://www.wikidata.org/wiki/Q317947 BCE 285 which differ from en.wikipedia 285 BC. This affects the connectivity between these two. Can it supports the BC format as well? הנדב הנכון (talk) 07:49, 20 June 2016 (UTC)[reply]

Examples corrected for time zone

Since the date of death incorporates the time zone, and the only time zone that can be used is UT, I have corrected the examples to name people who died in the UK. The examples are for people who died before summer time was instituted. Jc3s5h (talk) 09:47, 13 July 2017 (UTC)[reply]

Added qualifier

I added the qualifier refine date (P4241) per the example in the appropved property proposal. - PKM (talk)

Death of person/item about person

Please see Property_talk:P3342#Link_"death_of_(person)"_to_item_about_(person).
--- Jura 12:10, 6 March 2018 (UTC)[reply]

Gregorian Calendar

Can someone block the possibility of adding Gregorian Calendar to dates prior to October 5th, 1582? That would mean we don't have to change all those dates when we encounter them. And perhaps it would be a good idea to run a script to delete Gregorian Calendar everywhere it is now in the database with dates before that calendar was introduced. --HRvO (talk) 17:45, 21 January 2019 (UTC)[reply]

If a date is related to most of Europe and before 5 October 1582, it's pretty clear it must be a Julian calendar date. But if the date is from some other part of the world, and is converted from some calendar that is neither Julian nor Gregorian, it isn't so obvious whether it would have been converted to Julian or Gregorian. Jc3s5h (talk) 18:23, 21 January 2019 (UTC)[reply]

That is correct of course. I only work with European dates and there I noticed a lot of dates prior to October 5th, 1582 who are manually set to the Gregorian Calendar. So apparently there are users for who it is not “pretty clear it must be a Julian calendar date”. Is there a way to prevent this? An extra warning of some kind? --HRvO (talk) 22:03, 22 January 2019 (UTC)[reply]

One problem is that most of the import tools (QuickStatements, wikidata-cli, etc) don't seem to have any functionality for actually setting a date to be Julian - the system can default to Julian when it's added manually, and it usually does for pre-1582, but not for anything imported - that all goes in as Gregorian regardless of date. And, of course, a lot of stuff is automatically imported. Andrew Gray (talk) 15:08, 26 January 2019 (UTC)[reply]

It might be me, but shouldn't automatic importing be reconsidered then? Or always a manual check after the importing? --HRvO (talk) 15:46, 26 January 2019 (UTC)[reply]

Range constraint

This brings up an error message when somebody died "today" but it's still "yesterday" in the UTC timezone. I suggest that a day's leeway is given before this error is triggered. Case in point in Q444691 who died this morning (6 March), but it's still only 5 March in Europe. Schwede66 (talk) 19:19, 5 March 2020 (UTC)[reply]

Ok, it turns out she died late last night (5 March) but the issue still exists. Schwede66 (talk) 20:00, 5 March 2020 (UTC)[reply]

21st century

The 21st century is 2000 until 2100. According to Wikidata the 21st century is in the future. See for instance: Q94741880

At [1] it's showing up as 2100s; but should be 21st century.SportsOlympic (talk) 12:00, 22 July 2020 (UTC)[reply]

Erroneous warning when date of birth and date of death are both century precision

Consider for instance Romanos Dalassenos (Q19894687) who has a date of birth (P569) as "10. century" and a date of death (P570) as "11. century". However, a warning appears saying "The difference between date of birth (10. century) and date of death (11. century) should be between −1 year and 150 year." This is in error, since by definition the 10th century is 901-1000 and 11th century is 1001-1100, and thus is aged between 0 and 100 years old. I don't have the expertise to fix it, and would be obliged if someone who does could do so. -Thunderforge (talk) 05:50, 15 December 2020 (UTC)[reply]

User:Thunderforge doesn't make it clear under what circumstances this error occurs. Also, this probably doesn't affect the issue, but I don't think it's clear whether the 10th century, for Wikidata purposes, is 900 to and including 999, or 901 to and including 1000 (and similarly for the 11th century). Jc3s5h (talk) 16:00, 15 December 2020 (UTC)[reply]

Jc3s5h, I gave an example item that has this behavior. Do you want more examples? I don't know what else I can do to "make it clear under what circumstances this error occurs". As for the years, I was going off of Wikipedia's articles for 10th Century and 11th Century, which clearly state that they are 901-1000 and 1001-1100 respectively. I don't see any reason that Wikidata would behave differently. -Thunderforge (talk) 16:29, 15 December 2020 (UTC)[reply]

For centuries the last two digits are not significant. The contents was +0901-00-00T00:00:00Z and +1100-00-00T00:00:00Z so the difference (199) is more than the threshold. Fixes that would changing the meaning. Multichill (talk) 19:47, 15 December 2020 (UTC)[reply]

Date of birth constraint

I added the date of birth (P569) because someone who died must have been born some day. Currently 179 constraints are reported (might still be populating). Even if it's 10 times more it would still be less than 0.1% of all usage (about 2.5M) so I'm a bit puzzled by this edit. @Valentina.Anitnelav: care to elaborate? Multichill (talk) 19:08, 27 February 2021 (UTC)[reply]

@Multichill: I did not remove the constraint and I don't oppose it. I just added constraint status (P2316) suggestion constraint (Q62026391) as it is often the case that only the death date is known (not the birth date). It would be an improvement to the item to add the birth date but it is not a sign of wrong use of date of death (P570) if there is none. "Currently 179 constraints are reported (might still be populating)." This number seems to be wrong. There are 889 "violations" for actors alone (query). Without the restriction to actors the query times out. - Valentina.Anitnelav (talk) 19:33, 27 February 2021 (UTC)[reply]

One addition: it is the same situation as with gender (which is also added as a item-requires-statement constraint (Q21503247)/suggestion constraint (Q62026391) constraint), place of birth, place of death and even parents (every person with a death date has parents). It is an improvement to the item to add them but not a sign of wrong use of date of death (P570) if they are not added - Valentina.Anitnelav (talk) 19:36, 27 February 2021 (UTC)[reply]

The difference is with gender that it can really be unknown. The date of birth is never really unknown if we know when someone died. I doubt any actors wasn't born in the 2nd millennium. I removed the suggestion rank. That's not applicable in this case. All these people should have the date of birth statement. Multichill (talk) 22:08, 27 February 2021 (UTC)[reply]

Hi everyone, I'm new to this topic. I'm wondering is the date of birth constraint can be softened? We can't know the date of birth of all actors, even when we know their date of death.James nayler is real (talk) 15:39, 18 June 2021 (UTC)[reply]

I agree. It seems ridiculous to me to flag as an error a biographical item for which the date of death happens to be known but the date of birth happens to be unknown. It happens all the time and is not an error. —David Eppstein (talk) 05:23, 18 September 2021 (UTC)[reply]

I totally agree. There is nothing wrong with adding some information just because some other information is not known. And in practice it is very common for historical people that only the date of death is known, and that the date of birth is lost and will never be known. Even the suggestion "An entity with date of death should also have a statement date of birth" is off-putting and can maybe lead to people avoid entering information. Can we not get rid of this completely? Pst (talk) 08:47, 24 June 2023 (UTC)[reply]

I'd also point out that sometimes we have the date of baptism, but that still triggers the 'should have a date of birth' message. DS (talk) 13:02, 29 July 2023 (UTC)[reply]

I agree that it does not make sense to require this constraint. To that end, I have removed it from the property. Schwede66 (talk) 22:14, 15 August 2024 (UTC)[reply]

Range of years in P570

Hi! I would like to describe a condition on Q106713676. It is a list of persons, who died between 1941 and 1945 (time of NOB). Current placement of properites is returning an error or warning. Sadly, this attribute of time of death is among the occupation of persons really important. I am not sure how to correct the range of 4 years timespan. Thanks in advance. --A09090091 (talk) 09:23, 11 May 2021 (UTC)[reply]

January 1 as date

Please note Help:Dates#January_1_as_date. --- Jura 16:10, 1 February 2022 (UTC)[reply]

Bogus error

Template is throwing out errors for "Born in 13th century" "Died c. 1265", thinking that those dates aren't in the range of -1 to 150 years. Fix it when you've got time. — LlywelynII (talk) 19:17, 15 May 2024 (UTC)[reply]

Property talk:P570

Contents

Documentation

Queries

people with dates of birth and death on January 1st (day precision dates)

Discussion

Keeping up to date

Died "after 1110"

Living people and no value

Dates available at Wikipedia

Death during the night ?

Declared dead

Value for reason for deprecated rank (P2241)

BCE / BC

Examples corrected for time zone

Added qualifier

Death of person/item about person

Gregorian Calendar

Range constraint

21st century

Erroneous warning when date of birth and date of death are both century precision

Date of birth constraint

Range of years in P570

January 1 as date

Bogus error

Navigation menu

Property talk:P570

Documentation

Queries

people with dates of birth and death on January 1st (day precision dates)

Discussion

Keeping up to date

Died "after 1110"

Living people and no value

Dates available at Wikipedia

Death during the night ?

Declared dead

Value for reason for deprecated rank (P2241)

BCE / BC

Examples corrected for time zone

Added qualifier

Death of person/item about person

Gregorian Calendar

Range constraint

21st century

Erroneous warning when date of birth and date of death are both century precision

Date of birth constraint

Range of years in P570

January 1 as date

Bogus error

Navigation menu

Search