Property talk:P570

From Wikidata
Jump to navigation Jump to search

Documentation

date of death
date on which the subject died
DescriptionDeath date of a living thing, see also date of birth (P569).
Representsdate of death (Q18748141)
Data typePoint in time
Domain
According to this template: person (Q215627), organism (Q7239)
According to statements in the property:
human (Q5), fictional character (Q95074), organism (Q7239), person (Q215627), legendary figure (Q13002315), group of humans (Q16334295) or human whose existence is disputed (Q21070568)
When possible, data should only be stored as statements
Allowed values
According to this template: Past dates, obviously posterior to the date of birth (P569) of the same item
According to statements in the property:
3200000 ≤ 𝓧 ≤ unknown
When possible, data should only be stored as statements
ExampleRamesses I (Q1526) →
Isaac Newton (Q935) →
Edgar Leopold Layard (Q553155) →
Victor Grayson (Q7925945) → unknown
Walter Altschul (Q60544126) →
Format and edit filter validationAbuse filter #55
Tracking: differencesCategory:P570 different in Wikipedia (Q23037969)
Tracking: usageCategory:Pages using Wikidata property P570 (Q20117080)
Tracking: local yes, WD noCategory:Property P570 missing at Wikidata, but information available in Wikipedia (Q20113586), Category:Articles with Template:Bio and date of death not in Wikidata, but available on Wikipedia (Q28858520)
<complementary property>date of birth (P569), date of baptism (P1636)
See alsodate of disappearance (P746), floruit (P1317), place of death (P20), cause of death (P509), manner of death (P1196), date of burial or cremation (P4602), place of burial (P119), date of birth (P569)
Lists
Living people protection classproperty likely to be challenged (Q44597997)
Proposal discussionProposal discussion
Current uses
Total3,515,573
Main statement3,505,11999.7% of uses
Qualifier6,8280.2% of uses
Reference3,6260.1% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
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
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), Grace Augustine (Q116257868), Eytukan (Q116312762)
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
 
Person properties
Name
Birth
Death
General
Education
Profession
Views
Body
Family
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

[edit]

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

[edit]
#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

[edit]

Keeping up to date

[edit]

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"

[edit]

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

[edit]

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]

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:

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]
@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]

Dates available at Wikipedia

[edit]

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 ?

[edit]

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

[edit]

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)

[edit]

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

[edit]

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

[edit]

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

[edit]

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


Death of person/item about person

[edit]

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

Gregorian Calendar

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

Bogus error

[edit]

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]

Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P570&oldid=2285610827"