Property talk:P421

From Wikidata
Jump to navigation Jump to search

Documentation

located in time zone
time zone for this item
Representstime zone (Q12143)
Data typeItem
Template parametertime_zone in en:Template:Infobox country
Domaingeographic location (Q2221906), standard time (Q1777301), daylight saving time (Q36669), time zone named for a UTC offset (Q17272482), geographic entity (Q27096213), occurrence (Q1190554) and shooting attack (Q12410555)
ExampleGermany (Q183)UTC+01:00 (Q6655)
Montreal (Q340)Eastern Time Zone (Q941023)
India (Q668)UTC+05:30 (Q6828)
Tracking: sameno label (Q24194634)
Tracking: differencesno label (Q24194633)
Tracking: usageCategory:Pages using Wikidata property P421 (Q23908992)
Tracking: local yes, WD noCategory:Located in time zone not in Wikidata, but available on Wikipedia (Q24194632)
Lists
Proposal discussionProposal discussion
Current uses1,469,799
Search for values
[create] Create a translatable help page (preferably in English) for this property to be included here
Value type “time zone (Q12143): This property should use items as value that contain property “instance of (P31)”. On these, the value for instance of (P31) should be an item that uses subclass of (P279) with value time zone (Q12143) (or a subclass thereof). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P421#Value type Q12143, SPARQL, SPARQL (new)
Qualifiers “valid in period (P1264), applies to part (P518), start time (P580), end time (P582), statement is subject of (P805): this property should be used only with the listed qualifiers. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P421#Allowed qualifiers, SPARQL, SPARQL (new)
Conflicts with “instance of (P31): human (Q5): this property must not be used with the listed properties and values. (Help)
List of this constraint violations: Database reports/Constraint violations/P421#Conflicts with P31, hourly updated report, search, SPARQL, SPARQL (new)
This property is being used by:

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

Discussion[edit]

Named time zones or UTC?[edit]

In most cases, there is a choice: to use a named time zone or offset from the UTC (e. g. Central European Time (Q25989) and UTC+01:00 (Q6655)). I think that should give preference to a named time zones. —putnik 14:52, 7 April 2015 (UTC)

Hmm. Why aren't we leaving this up to the IANA's timezone database tz database (Q187176)? Timezones are REALLY REALLY fiddly, do not lend themselves to wikidata's simple data model, and are always getting changed; IANA's database is kept up-to-date while still retaining historical information, so any timedate can be accurately converted (well, since 1970 at least—the database doesn't account for zones that merged before then). It also has the handy property that zones are referenced by the names of important cities in those zones. The names of these cities, as a general rule are not subject to dispute, do not change often, and are fairly unique. —SamB (talk) 04:56, 11 April 2015 (UTC)

Most places have two timezones[edit]

A standard one and one for summer (CET / CEST, CST / CDT). Is there a qualifier for this or a separate property?

On the page for Stuttgart, e.g., I used ("is a") to denote the claim as "daylight saving time". Is this agreeable?

Harald82 (talk) 09:25, 24 April 2015 (UTC)

Use valid in period (P1264) as qualifier! There is also Troll (Q1082371) that switches between UTC+0, UTC+1 and UTC+2 during the year, i.e. 'three time zones during a single year. -- Innocent bystander (talk) 06:16, 30 August 2017 (UTC)

Related property proposal[edit]

@putnik, SamB: from #Named time zones or UTC?. Please comment on my property proposal for Wikidata:Property proposal/Equivalent Timezone. -- T.seppelt (talk) 06:03, 15 June 2016 (UTC)

Start and end time not allowed as qualificators[edit]

Sudan changed time zone from UTC+03 to UTC+02 on 2017-11-01. I tried to indicate that with qualificators start time (P580) and end time (P582) but it seems they aren't valid for this property. I assume this is an oversight, so how to change that? --Dipsacus fullonum (talk) 18:19, 15 June 2018 (UTC)

Marking as deprecated the obsolete time zones[edit]

Is there an automatic way to mark as deprecated the obsolete time zones when two or more time zones are indicated? For example, in Q135285 there is UTC+3 until 27 mar 2016 and UTC+4 since 27 mar 2016. In this example the old time is marked as deprecated so everything works correctly, but there a lot of other occurrences when it is not, so that the other wiki-projects are usually not able to import the current time.--Antenor81 (talk) 15:00, 14 December 2018 (UTC)

  • If a zone is no longer applicable, it should have an end date and normal rank, not deprecated rank. The current time zone would have preferred rank. See Help:Ranking. Bots can do such changes. Try Wikidata:Bot requests. --- Jura 15:05, 14 December 2018 (UTC)
Ok, thank you!--Antenor81 (talk) 15:11, 14 December 2018 (UTC)

Named time zones or UTC, again[edit]

I'd like to reopen the question of "Named time zones or UTC?". Right now our encoding of time zones for locations is mixed and inconsistent. (Statistics below.) So the first question is, are we okay with this, or is it worth improving? It seems to me that using one consistent scheme would be much better than the current mixture, but I'm relatively new here, so I could be wrong.

Is our mixed encoding an actual preference (perhaps to make it more convenient for people adding timezones, or to avoid stepping on people's toes)? Or did it just arise by accident? Would there be resistance to an effort to standardize on one encoding scheme? How many people even care about time zones?

For reference, I've done some research on our current encodings. Out of 369 actual time zones that we currently have -- that is, entities which are instances of time zone (Q12143) -- 74 are time zone named for a UTC offset (Q17272482), 78 are named time zones, and 217 are IANA time zone (Q17272692). Usage is as follows:

zone type number of zones used for at least one entity unused number of entities tagged
numeric UTC 74 44 30 1718969
named 78 62 16 122090
IANA 217 33 184 145

So the numeric UTC zones are far and away the most "popular" -- but of course this isn't a popularity contest. I suspect (but have not proved) that the preponderance of numeric UTC zones is simply due to their being imported from the wikipedias, which tend to represent time zones that way.

Me, although as I've said I'd like to see more consistency, I would not be in favor of just standardizing on the numeric UTC zones. From a data quality standpoint, I believe that the named zones are more useful, and the IANA zones more useful still. (More on this later.)

But I'd very much like to hear what other people think. Scs (talk) 14:37, 22 March 2019 (UTC)

As you mention, the source for what's in there right now is most likely what was provided on the existing Wikipedia pages. We recommend providing some sort of source for all statements, so maybe the first thing is to find a good source that lists geographic locations and their time zones? As to what should be preferred - for locations that don't have a "Daylight Savings" or other time change during the year, I don't see that it really matters much (as long as the statement is correct). For locations with a time change, the numeric UTC zone is simply wrong - it should be replaced with the correct zone - I think IANA zone is probably best (with start/end time qualifiers as appropriate). Do named zones include DST changes? ArthurPSmith (talk) 16:02, 22 March 2019 (UTC)
Some of the named zones do include DST and some don't -- so this is another area of inconsistency. For example, Eastern Time Zone (Q941023) is qualified for both standard time and daylight time, but Central European Time (Q25989) is not. So Luxembourg (Q1842) is wrong since it's tagged only CET, but Poland (Q36) does it right by linking to both Q25989 and Central European Summer Time (Q207020). (And there are plenty of places that link to two UTC zones, with valid-in-period qualifiers, e.g. Berlin (Q64).) Scs (talk) 16:29, 22 March 2019 (UTC)
Using start and end times for IANA time zones is hard to think about, and arguably unnecessary, because IANA zones already contain complete historical data; effectively every correct statement involving P421 and an IANA zone is valid since 1970 and has never (by definition!) changed since then. (But I don't want to get sidetracked on discussions of the fascinating aspects of IANA timezones just yet; first I'd like to gauge the appetite for change from the status quo at all.) Scs (talk) 16:44, 22 March 2019 (UTC)
Indeed. The only time when we would even need to do anything is when they have to split zones, and the new zone(s) would still have all the relevant historical data, so we wouldn't really need the old zone ID at that point.
And that is why I'm very much in favor of using the IANA zones. --SamB (talk) 03:34, 14 May 2019 (UTC)
  • I think the property is popular for items about places in the PRC. These all happen to be using the same value. --- Jura 14:53, 23 March 2019 (UTC)

proposed IANA timezone ID property[edit]

Those interested in time zones may be interested in this proposed property to link each IANA time zone (Q17272692) to its official ID in the tz database (Q187176). Scs (talk) 17:53, 5 April 2019 (UTC)