Property talk:P580

Documentation

start time
time an entity begins to exist or a statement starts being valid

Description

The time the claim began being valid, often paired with end time (P582). For creation date, rather use inception (P571) or service entry (P729).

Represents

start time (Q24575110)

Data type

Point in time

Domain

Any claim that is valid within a certain range of time (note: this should be moved to the property statements)

Allowed values

any (bot hint: should be < to the corresponding end time (P582)) (note: this should be moved to the property statements)

Example

According to this template: New York was the capital of the United States from January 11, 1785. (Gregorian date)

According to statements in the property:
Japan (Q17) → 10 January 1920
Péter Medgyessy (Q156487) → 27 May 2002

When possible, data should only be stored as statements

Robot and gadget jobs

DeltaBot does the following jobs:

Move source to qualifier

Tracking: same

no label (Q42533403)

Tracking: usage

Category:Pages using Wikidata property P580 (Q20990068)

end time (P582), dissolved, abolished or demolished date (P576)

External Use[edit]

This property is being used by:

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

Use of "no value"[edit]

Moved from Property talk:P582. --Yair rand (talk) 19:47, 11 April 2016 (UTC)[reply]

In certain items such as Q17, "end date: no value" is used to indicate that the statement is true as of now. In my opinion, it would be better just to leave it blank, as otherwise the qualifier would need to be added to pretty much everything, and additionally can cause statements to be inaccurate as opposed to incomplete if the status changes. Thoughts? --Yair rand (talk) 02:04, 19 June 2013 (UTC)[reply]

@Yair rand: I tend to agree, for a context specific question, see Property_talk:P39#Current_office-holders. --- Jura 11:49, 7 September 2015 (UTC)[reply]

Two ranges of time[edit]

Say politician A was in political party X from 2005 to 2009. Then he left the party in 2010. Then return to the party in 2012 and left again for the second time in 2013. So this would mean that two qualifier sets of start time (P580) and end time (P582) would be needed for member of political party (P102). How do we signify that start_date1 corresponds to end_date1 and not end_date2? --Wylve (talk) 14:01, 26 June 2013 (UTC)[reply]

The same case is with head of government (P6). I think it could be resolved as separate statements. There is rank available with each statement. For all historical statements the rank is set to normal but for the current one it shall be set to preferred. So in real-life scenario the rank=preferred shall be used with single start time (P580) property and rank=normal if both start time (P580) and end time (P582) are provided. Unfortunately, I could not find method to edit the rank value. It is only visible in Lua scripts as normal. Paweł Ziemian (talk) 11:42, 6 July 2013 (UTC)[reply]

I've added {{Constraint:Single value}} to replicate this in the constraint reports. (Do the constraints work on qualifiers as well?) -- Bene* ^t_a^l_k 13:41, 10 April 2015 (UTC)[reply]

Geologic time[edit]

How can I input that the Holocene (Q25445) started 11700 years ago? --Tobias1984 (talk) 10:15, 31 July 2013 (UTC)[reply]

Both Gregorian and Julian calendars are supported. So perhaps you can just pick one and use a backdated date (e.g. 9700 BCE). You are also able to specify precision to century, millenium, etc (under advanced adjustments). Superm401 - Talk 18:45, 1 October 2013 (UTC)[reply]

And that the Darriwilian (Q1032866) started 467.3 ± 1.1 million years ago (the more usual kind of dates in geologic timetable)? --PePeEfe (talk) 08:54, 19 November 2016 (UTC)[reply]

Approximate times[edit]

I recently discovered that one can also enter the decade using this property rather than a concrete year or date. This is useful when you only know, as an example, that a certain event took place "about" 1925 – then you enter "1920s". But what if this event did not take place in the middle of the decade but at the beginning/end or turn of the decade? Then it is not clear which decade should be entered.--Leit (talk) 00:05, 5 February 2014 (UTC)[reply]

@Leit: Thank you for bringing this up already six years ago! Have you found an answer elsewhere yet? In my opinion, even specific dates are approximate too, given that you can't specify a higher precision than day (I see there has been a lot of talk about that; I'm not going there now). But your question relates to the issue of matching end/start times of adjacent periods, such as when one person replaces another in a public office, or a geographic entity changes name or political/administrative affiliation.

If a formal change is declared to take place at a particular date, say January 1st of some year, then the new period is generally assumed to include that entire day, so it effectively begins at 1 January 00:00:00 (midnight, local time). But when does the previous period end? I have seen cases of the end date sometimes specified as December 31 the previous year, sometimes as January 1 of the new year (i.e. identical to the start of the new period). I don't know yet which usage is currently most common on Wikidata, but in general parlance, saying that something ends on January 1st hardly ever means that the old state of things remains true throughout January 1st until 23:59:59 (next to midnight), with the new period commencing only on January 2 00:00:00; it means that the old state of things ceases at the very beginning of January 1st 00:00:00.

Partly for the reason you mention, but also to make dates of change easier to enter and lists of successive periods easier to read, I would argue that the start time should be viewed as inclusive while the end time is regarded as exclusive. In that way, it won't matter at what precision you know the time of a change; if the new period begins in 1925 (date unknown), the previous period will end "in" 1925 too, and if the new period begins the 1920s, the old one will end in the 1920s too, even if the change actually took place on January 1st, 1920, and you won't have to worry about fencepost errors due to low precision knowledge of when an event took place.

This argument of course does not apply when you actually have an interim period of transition, such as the vacancy of an office when its previous holder has died or resigned, and the successor has not yet been appointed or been able to effectively take that office into possession.

As always, anyone's comments are welcome (especially conflicting opinions based on contradictions of the examples I have given). --SM5POR (talk) 12:27, 4 July 2020 (UTC)[reply]

refine date (P4241) is generally used for this. There are early discussions about using Extended Date/Time Format Specification (Q57629619) in Wikidata; EDTF has markup to indicate both precision and accuracy (and timespans in one string rather than splitting into start and end as WD currently does) but it's unclear how statements that would predate such a hypothetical adoption would get migrated, or if they would. Arlo Barnes (talk) 06:50, 16 December 2021 (UTC)[reply]

exact time[edit]

Tracked in Phabricator
Task T57755

How do I specify the exact start and end times of an event? For examples transit of Venus, 1639 (Q3537644) began at 4 December 1639 14:57 and ended at 21:54 UTC. --Mu301 (talk) 22:42, 6 February 2016 (UTC)[reply]

I am also having difficulty entering an exact time. For example I put in "May 14th 2017 8:00pm" and it says "will be displayed as +2017-05-14T20:00:00Z" but when I save, I get the error "Could not save due to an error. Malformed input: +2017-05-14T20:00:00Z". This seems to be a bug. Devon Fyson (talk) 05:33, 28 July 2017 (UTC)[reply]

@Mu301, Devon Fyson: maximum time precision is currently day, not hour or minute. See Phabricator:T57755 from 2013.
--- Jura 07:07, 28 July 2017 (UTC)[reply]

Used as qualifier only ?[edit]

Moved from Property talk:P582. --Yair rand (talk) 19:47, 11 April 2016 (UTC)[reply]

Hi,

This property have itself the property instance of (P31) = Wikidata qualifier (Q18615010). Logically, I added the constraint « this property can only be used as a qualifier » (Special:Diff/302962998) and logically too Swpb reverted me (Special:Diff/303185675).

I believed the situation was : « using end time (P582) as qualifiers only and using other and more specific ending property otherwise (date of disappearance (P746), dissolved, abolished or demolished date (P576), date of death (P570), service retirement (P730), etc. depending on the context) » but indeed, the situation seems to be unclear and end time (P582) is used on 11,701 items (some are strange but others seems legit) ; moreover, the description says « The time the claim ended being valid, usually as a qualifier ».

So is it « only » or « usually » ? The information is contradictory and conflicting; it would be better to clarify it.

Same situation for start time (P580).

Cdlt, VIGNERON (talk) 18:34, 12 February 2016 (UTC)[reply]

I would not even go so far as to say that these properties should "usually" be qualifiers; I think they are perfectly acceptable as item properties in themselves. Surely, for items about events, the meaning of "start time" and "end time" is clear. As you say, the properties are already being widely used that way; I think that is because such use is natural and generally self-explanatory. Swpb (talk) 17:19, 16 February 2016 (UTC)[reply]

Battles and television series seem to be frequent users as a statement property Query
--- Jura 17:52, 16 February 2016 (UTC)[reply]

@Swpb, Jura1: so should we remove instance of (P31) Wikidata qualifier (Q18615010) on start time (P580) and end time (P582)? Cdlt, VIGNERON (talk) 09:53, 25 February 2016 (UTC)[reply]

Update (May 2018): See further discussion discussion on Project chat. --Oravrattas (talk) 11:27, 10 June 2018 (UTC)[reply]

The discussion on Project chat was about the difference between P571 (inception) and P580 (start time). In my view, P580 (start time) is better suited for events (not recurring ones, but single events, or instances of recurring events) and event-like items than P571 (inception). So P580 (start time) should not be made qualifier-only. I am surprised that Máté's opinion in the discussion on Project chat is just opposite of mine. I cannot help guessing that Máté probably confused P571 with P580 (sorry if my guess is wrong). I think that P571 (inception) is suited for organizations and other relevant entities, not events.--Neo-Jay (talk) 14:03, 10 June 2018 (UTC)[reply]

@Neo-Jay: Obviously, I got the IDs mixed up, the context makes it evident. Also, I was not expressing my opinion but a vague memory of another discussion I read. – Máté (talk) 16:00, 10 June 2018 (UTC)[reply]

@Máté: Thank you for your clarification. :) --Neo-Jay (talk) 16:04, 10 June 2018 (UTC)[reply]

Merge with P1326 ?[edit]

Moved from Property talk:P582. --Yair rand (talk) 19:47, 11 April 2016 (UTC)[reply]

I can't see any objective difference between properties end time (P582) and latest date (P1326). Both should be merged. Or something is missing to distinguish them if there's a difference. Verdy p (talk) 12:18, 28 February 2016 (UTC)[reply]

"end date" = date when an event ends
"latest date" = any date before and including a given date. Latest date should be a qualifier for date properties in general. It could a qualifier on an "end date" (e.g. unknown"). At some point, date properties should include the difference in precision directly and "latest date" could be deleted.
--- Jura 12:28, 28 February 2016 (UTC)[reply]

дата начала процесса[edit]

Есть такая? --Fractaler (talk) 11:22, 16 August 2016 (UTC)[reply]

Не в курсе, я бы моделировал процесс отдельным свойством, где элементы-значения - это стадии процесса.

Процесс "строительство дома":

планирование и проектирование
согласование проектной документации
передача документов строителям-подрядчикам
начало строительства, строительство, завершение строительства
презентация сооружения (праздничное событие)
введение здания в эксплуатацию

У стадий можно свойства начала-конца даты указывать как квалификаторы.

Такой подход позволяет указать нарушения (пропущенное проектирование, "начало процесса" со второй стадии).

Более опытные участники могут подсказать точную модель. d1g (talk) 18:54, 4 January 2017 (UTC)[reply]

Constraint against Event should be removed or replaced[edit]

It seems that the Event constraint for an instance type is not appropriate in many cases. The constraint violation report is now VERY large. For example: cuneiform Q401 is not an event, but a writing style that had an inception or start date and a generally acknowledged end date. It seems wiser that the constraint should be higher up like 'temporal entity'. I created that new item for this purpose: https://www.wikidata.org/wiki/Q26907166 Any Thing could have a temporal state. And only 1 thing cannot = Time itself. When a Thing has been determined by common sense or a historical perspective to have had a 'temporal occurance' or happening, then I would think that it could be classed as a 'temporal entity' and not an event. There are no restrictions.
---- Thadguidry (talk) 03:03, 17 September 2016 (UTC)[reply]

Support. Thryduulf (talk) 10:43, 17 September 2016 (UTC)[reply]

Oppose because of the example. A writing system is not an event, it has a period where it's used, but it does not cease to exists after it's end main period of usage and can still be studied or event written later. author TomT0m / talk page 14:29, 19 October 2016 (UTC)[reply]

Comment see also Chicago Card (Q5095525) (now defunct) and Ventra (Q7920279). d1g (talk) 15:48, 4 January 2017 (UTC)[reply]

Start and end dates for positions held[edit]

These properties are very useful, and widely used in Wikipedia, as qualifiers of positions held by people. However, it is not always clear how a start date and an end date exactly mean in these cases. For example, catholic bishops are "appointed" at a date, and ordained some time later. I would have though the ordination date was the one to be used, but that is not how catholic-hierarchy.org does it (see [1] and [2]). For ambassadors, the date might be either when she is nominated or when the hosting country accepts her nomination.

How should we solve it ? Create subproperties so that we can document things in full ? Make a list of events that we shall use for start time (P580) and end time (P582), something else ? --Zolo (talk) 07:31, 13 May 2017 (UTC)[reply]

I would love an "appointed on" property. I have various data sources that provice both dates. Sjoerd de Bruin (talk) 12:52, 26 September 2017 (UTC)[reply]

For now, using qualifiers for the two kinds of dates may help; applies to part (P518) for the general class or identity of object in context (P4626) if the event itself has an item. Arlo Barnes (talk) 06:54, 16 December 2021 (UTC)[reply]

planned end?[edit]

Please see Wikidata:Property_proposal/expiration_date.
--- Jura 07:47, 17 August 2018 (UTC)[reply]

Precision Minute[edit]

Hello,

is it possible to add a precision Minute to this Property. I am interested in the history of parliaments and there for example in legislative terms of the German Reichstag from 1871 to 1918. I want to add items for the meetings of the different legislative terms of the German Reichstag in the mentioned time. In the Reichstagsprotokolle you can find the start time and end time of the meetings in a precison of Minute and I think it were great if it is possible to add it. -- Hogü-456 (talk) 18:13, 21 September 2019 (UTC)[reply]

I would also be interested in this for noting when particular online newspaper articles were published Digi-ark (talk) 17:05, 5 December 2020 (UTC)[reply]

Hogü-456 and Digi-ark, in case you've not yet discovered it, you can use the qualifier refine date (P4241) to provide an exact time for this property. It's not a perfect solution, but it gets the point across. — Huntster (t @ c) 18:40, 23 February 2021 (UTC)[reply]

Huntster exactly what I needed. Thank you. Digi-ark (talk) 14:58, 26 February 2021 (UTC)[reply]

When it is clear that something has ended, but the end time is unknown[edit]

I am editing the work history of a person. I have a reference that states that they held a certain job when they were younger, but no specific end time is given. How can I note that the particular job has ended? I have tried inserting end time: unknown, but wikidata would not accept that as a value. Thanks. Ottawajin (talk) 14:17, 1 August 2022 (UTC)[reply]

Ottawajin, you can use end time (P582), but instead of putting anything in the value field, click on the three boxes to its left. You'll see "no value", "unknown value", and "custom value". No Value can be used to indicate a property has null value instead of leaving a property out altogether (such as when a job is ongoing and "end date" is invalid), and Unknown Value is good for when you want to indicate a property is relevant but the value is unknown; in this case, the end date of the job. Make sense? — Huntster (t @ c) 14:37, 1 August 2022 (UTC)[reply]

Thanks so much for the quick reply. I'll give it a try. Cheers. 👍 Ottawajin (talk) 14:49, 1 August 2022 (UTC)[reply]

"subject named as..." qualifier[edit]

It is permitted with inception but not permitted with end time. Any logic here? Retired electrician (talk)

Start/end time or inception/dissolved date for legislative term?[edit]

@Oravrattas: Why did you replace P580/P582 (start/end time) with P571/P576 (inception/dissolved date) on many items about legislative terms (e.g., this and this)? Is there any consensus on this issue? Legislative term (Q15238777) is subclass of occurrence (Q1190554) although it may also be seen as subclass of organization (Q43229). It seems to me that start/end time is more appropriate than inception/dissolved date for items about legislative terms. --Neo-Jay (talk) 14:31, 22 February 2023 (UTC)[reply]

@Neo-Jay: That has been the documented model for a very long time: see Wikidata:WikiProject_Parliaments#For_parliamentary_terms. --Oravrattas (talk) 14:51, 22 February 2023 (UTC)[reply]

@Oravrattas: Thank you for the information. But, I am wondering whether there had been any discussion before the rule was made. I cannot find any discussion on this issue on Wikidata talk:WikiProject Parliaments or Wikidata talk:WikiProject Parliaments/Legislative Term Model. It is still not clear to me that inception/dissolved date is better than start/end time. Lots of items about legislative terms used or still use start/end time instead of inception/dissolved date. This indicates that many editors disagree with the rule. --Neo-Jay (talk) 15:23, 22 February 2023 (UTC)[reply]

@Neo-Jay: The continued inability to get any agreement on which of P580/P582 and P571/P576 should be used where, is probably the most annoying of any than I've ever had to deal with with Wikidata querying. Anything working with political data essentially needs to handle both, which gets really complicated really quickly if you need to be robust around them having different values / date precisions / rankings on them. I have less than zero interest in which is used—I just want usable data. And we seem to be moving further away from that over time, not closer to it. --Oravrattas (talk) 15:42, 22 February 2023 (UTC)[reply]

@Oravrattas: Thank you for your reply. So, does your reply mean that there had been no discussion before the rule was made? You yourself changed the rule from using P580/P582 to using P571/P576 (see this and this). Was this change based on your personal preference, not on community discussion? If you are not interested in which is used, why not allow items to have either, or both? Now P580 and P571 do not have "conflicts-with constraint" with each other (see this and this). Even if they do, we can keep the properties that are already used, and do not need to bother to replace them with others. When querying, we can use "?item (wdt:P580|wdt:571) ?start" to find all legislative terms with either P580 (start time) or P571 (inception), whose values are, presumably, the same. If you do not disagree, I will change Wikidata:WikiProject Parliaments/Legislative Term Model to allow items to have either P580/P582 or P571/P576, or both. Thank you.--Neo-Jay (talk) 16:49, 22 February 2023 (UTC)[reply]

No, it doesn't mean that at all, but thanks for arguing in bad faith. In most discussions I've seen the closest thing to consensus is that P580/P582 should usually only be used as qualifiers, notas main statements. In general I find that a good approach, but you've made it clear you don't. So please take this to a more appropriate setting and see if we can get consensus on this once and for all, rather than adding yet more confusion in this one specific area. Oravrattas (talk) 18:56, 22 February 2023 (UTC)[reply]

@Oravrattas: I have not argued in bad faith. Sorry that I gave you such an impression. You had not answered the question "whether there had been any discussion before the rule was made". So I thought there was no such discussion. And by "discussion", I mean the specific discussion on whether items about legislative terms should use P580/P582 or P571/P576, not general discussion on whether P580/P582 should be used as main values or as qualifiers (sorry if I did not clarify it). And P580/P582 actually can be used as main values (see "property scope constraint" here and here), especially for items about occurrences (Q1190554), which legislative term (Q15238777) is subclass of. The original rule in Wikidata:WikiProject Parliaments/Legislative Term Model was using P580/P582. If there had been no "specific discussion" before you changed it (see this and this), let's discuss it now. I personally think that legislative terms are primarily occurrences, not organizations (a legislature is the organization, and its legislative terms are its different periods). Before the edit made by you on 6 September 2022, legislative term (Q15238777) had not been subclass of organization (Q43229). Even if it could be seen as subclass of organization, this, in my view, is not its primary meaning. Therefore P580/P582 (start/end time) is more appropriate than P571/P576 (inception/dissolved date). But if you disagree, I think that we could reach a compromise that either (or both) of them can be used, and, to avoid edit war, the properties already used should not be replaced with others. For example, if P580 (start time) is already used, P571 (inception) with the same value can be added, but P580 should not be replaced with P571. What do you think? Thank you. --Neo-Jay (talk) 20:46, 22 February 2023 (UTC)[reply]

@Neo-Jay thank you for this response. In my experience most of the legislatures who name or number their terms also refer to people as being members of those (Member of the 5th Convocation; Deputy of the 19th Assembly, etc) in a way that would seem odd to me if those were primarily just periods. I suspect this is one of those things where most people's views will be shaped by how this works in the country or handful of countries they're familiar with, although it differs significantly in others.

However, as I said earlier, I don't really care so much which set of properties we use, as long as querying the data becomes easier, rather than harder. That doesn't necessarily mean that the queries themselves become simpler — clear documentation with good example can also achieve this — but in my experience allowing for either approach optimises for writing (which should largely be a 1 time thing) at the approach of making queries (which should happen many orders of magnitude more often) considerably harder. Your earlier example of alternation, for example, does not work well when both get filled in, causing a combinatorial explosion of results, for example:

SELECT ?item ?start ?end WHERE { VALUES ?item { wd:Q1319364 } ?item wdt:P580|wdt:P571 ?start; wdt:P582|wdt:P576 ?end . }

Try it!

And, as mentioned before, this gets much more complicated really quickly when a query needs to also work with rankings, qualifiers, precisions etc.

So whilst I don't really care whether we use P580/P582 or P571/P576 for these, I am much more strongly against leaving it open to either/both. There should be one clearly documented approach, and all the existing data should be migrated to whichever is chosen.

But that choice shouldn't be made by just the two of us, or on this page. At a minimum it should go to Wikidata:WikiProject every politician, but there's enough of a recurring issue around the difference between these two sets of properties to suspect this should really go to Project Chat instead.

(Genuine question: can you or anyone explain, or point me to somewhere that explains, what benefit we get from having both of these, or why they can't be consolidated into a single pair of properties? In my experience, any distinction between them seems incredibly subtle and inconsistently followed, and makes things somewhat harder when editing data and massively harder when querying or using the data.) Oravrattas (talk) 08:09, 23 February 2023 (UTC)[reply]

@Oravrattas: Thank you for your thoughts. The cause of the problem with your query above was that Q1319364 (The Games Machine) had different values for the two pairs of properties ("P580 (start time): November 1987" vs. "P571 (inception): 1987"; "P582 (end time): September 1990" vs. "P576 (dissolved date): 1990"). These values should be the same and I have corrected them. Now if "SELECT" is changed to "SELECT DISTINCT" in your query, the problem will be fixed:

SELECT DISTINCT ?item ?start ?end WHERE { VALUES ?item { wd:Q1319364 } ?item wdt:P580|wdt:P571 ?start; wdt:P582|wdt:P576 ?end . }

Try it!

Fixing this problem is relatively easy, and is, in my view, easier than reaching a consensus on which a single pair of properties should be used and replacing one pair of properties with the other one throughout Wikidata. I admit that my either/both solution is not an ideal solution, but a compromise. I also really hope that items can have just a single pair of properties. But I doubt that we can convince each other which single pair should be used. If you do not accept the compromise, I agree that this issue can be submitted to Wikidata:WikiProject every politician or Wikidata:Project chat. Will you submit it? Thank you. --Neo-Jay (talk) 13:27, 23 February 2023 (UTC)[reply]

Czech label[edit]

I changed the label from "od" to "začáteční čas": "od" is ambigous. The point of these properties is that they are specific. "od" could be an answer to the question "from whom"? There may be other, better design options, but it seems the ambiguity should be addressed. --Dan Polansky (talk) 11:12, 19 May 2023 (UTC)[reply]

Property talk:P580

Contents

Documentation

External Use[edit]

Use of "no value"[edit]

Two ranges of time[edit]

Geologic time[edit]

Approximate times[edit]

exact time[edit]

Used as qualifier only ?[edit]

Merge with P1326 ?[edit]

дата начала процесса[edit]

Constraint against Event should be removed or replaced[edit]

Start and end dates for positions held[edit]

planned end?[edit]

Precision Minute[edit]

When it is clear that something has ended, but the end time is unknown[edit]

"subject named as..." qualifier[edit]

Start/end time or inception/dissolved date for legislative term?[edit]

Czech label[edit]

Navigation menu

Property talk:P580

Documentation

External Use[edit]

Use of "no value"[edit]

Two ranges of time[edit]

Geologic time[edit]

Approximate times[edit]

exact time[edit]

Used as qualifier only ?[edit]

Merge with P1326 ?[edit]

дата начала процесса[edit]

Constraint against Event should be removed or replaced[edit]

Start and end dates for positions held[edit]

planned end?[edit]

Precision Minute[edit]

When it is clear that something has ended, but the end time is unknown[edit]

"subject named as..." qualifier[edit]

Start/end time or inception/dissolved date for legislative term?[edit]

Czech label[edit]

Navigation menu

Search