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 entity (Q27096213), standard time (Q1777301), daylight saving time (Q36669), time zone named for a UTC offset (Q17272482) or occurrence (Q1190554)
Allowed values
Usage notesTime zones should only appear in the higher administrative levels. Normally country, or state. If an administrative area changes time zones, the changes can be made easily.
ExampleGermany (Q183) → UTC+01:00 (Q6655)
Montreal (Q340) → Eastern Time Zone (Q941023)
India (Q668) → UTC+05:30 (Q6828)
Baranagar (Q712504) → Indian Standard Time (Q604055)
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 uses
Total2,009,020
Main statement2,006,53199.9% of uses
Qualifier2,4700.1% of uses
Reference19<0.1% of uses
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. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P421#Value type Q12143, SPARQL
Conflicts with “instance of (P31): human (Q5)”: this property must not be used with the listed properties and values. (Help)
List of violations of this constraint: Database reports/Constraint violations/P421#Conflicts with P31, hourly updated report, search, SPARQL
None of daylight saving time (Q36669): value must not be any of the specified items.
Replacement property:
Replacement 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/P421#none of, SPARQL
Scope is as main value (Q54828448), as qualifier (Q54828449): 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/P421#Scope, SPARQL
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/P421#Entity types
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Ok, thank you!--Antenor81 (talk) 15:11, 14 December 2018 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

It's there now. Property:P6687. Good idea, if used, then someone could make a bot script which corrects the "located in time zone" property, based on the database, when changed or if there are errors here.--BIL (talk) 07:10, 18 October 2019 (UTC)[reply]

New Property for Daylight Saving Time?[edit]

Hi. Do you believe that a new property "Time Zone (Daylight Saving Time)" additionally to this item would make sense? Currently, I do not really see a good way to express the Daylight Saving Time for a specific place. This could be done by using a second statement besides the time zone with this property.

An example for a city could be:

located in time zone (P421) → UTC−05:00 (Q5390)
Time Zone (Daylight Saving Time) (Pxxx) → UTC−04:00 (Q5762)

What do you all think about this idea? Or is there any better approach to have a statement about the Daylight Saving Time Zone in items of cities and places? Yellowcard (talk) 10:49, 5 July 2020 (UTC)[reply]

@Yellowcard: After seeing the earlier discussion above, plus your recent suggestion, I obtained some Wikidata statistics with respect to located in time zone (P421). It was interesting, in a watching-a-steam-elephant-derailment kind of way... Why is it that more than a thousand items (presumably places; my query isn't very sophisticated) associated with Thailand specify one and the same time zone, while Hong Kong needs only one item for that, and Haiti manages to specify two time zones with a mere five items? Is the time zone map really that complicated?
I would prefer applying some heuristic, like ?place wdt:P17/wdt:P421 ?zone to find the time zone specification valid for the entire country, and if that fails continue trying the smaller geographic entities until you find the zone (and likewise with any DST scheme specification). I mean, it's not like we have to specify currency used, electrical plug shapes, left or right hand side traffic, systems of weights and measures, languages spoken, or applicable jurisdictions for every single one of several million localities around the world, so why time zones? Are there more DST schemes in use globally than there are national currencies? Yes, there are exceptions, but I believe we can deal with those without spraying a "me too" property over any items that should go by the default value.
As to your DST property proposal, it doesn't look very expressive. Yes, you can use it to set your clocks three hours forward instead of just one, but how useful is that? I'd rather pick a named scheme, such as "European DST", "North American Standard DST", "Arizona DST", "Navajo DST", "Australian DST" and so on, where each scheme also contains information on when to switch. But before going further in that direction, I'd like to know more about the IANA approach referred to above. Maybe it handles the DST issue as well?
But regardless of the solution chosen, I bet that we risk wasting considerably more than 1,920 hours of CPU time processing an 80 million+ item database where one item out of ten matches a time zone, DST scheme, or any other duplicated statement if we don't find a territorial association method to establish default values. --SM5POR (talk) 23:15, 5 July 2020 (UTC)[reply]
@SM5POR: Thanks a lot for your reply and the quick analysis of the Status quo.
As for countries that have only one time zone for all of their places, I agree with you: It would not make sense to have a Time Zone statement in every single city/quarter/... item but it would be all enough to have the statement in the country item.
However, there are plenty of countries that have multiple time zones, and neither they always align on province/state/county level. Therefore, for these countries (such as the United States and Canada), I believe that a statement in each city item would be reasonable.
Whenever there is a time zone statement (independent of country/province/city level), a "Daylight Saving Time" statement would make also sense. Your idea of using a "DST scheme" such as "North Amerincan Standard DST" sounds good to me, as these enitites would allow to specify more information (such as beginning and ending weekend etc.).
In the European Union, there have been discussions about the DST going on for the last years, and it could happen that all countries will find individual DST rules at some point in the near future.
Again, thanks a lot for your input. I would like to find any solution better than the Status Quo and your ideas are very interesting. Let's continue this (either here or somewhere else). I will not request a new property before we have finished this discussion and have hopefully found a good approach. BR Yellowcard (talk) 06:49, 6 July 2020 (UTC)[reply]
@Yellowcard: Since the issues of time zones and daylight savings time schemes are closely related (you could hardly even apply a DST scheme without knowing what time zone you are supposed to use), I suggest we keep the discussion here for the moment.
Yes, there are countries with multiple time zones, but that doesn't seem a valid reason to immediately resort to city-specific time zone claims, if the answer can be found at a higher level. In the USA, you have the 50 states plus the District of Columbia; approximately how many of them use more than one time zone and one DST scheme? Then descend further down to county (or parish, or indigenous nation, or whatever local territorial unit is used in Alaska, Arizona, Hawaii, Louisiana or Rhode Island) level only in those, while asserting a state-wide time zone in the rest. At some point, when a decision is made to use a time zone different from the rest of the state or county, I suppose someone has to make a map or list showing which cadastral units the decision will apply to, and then it would make sense to import the contents of this document into Wikidata, so that the affected localities can be associated with it.
But we need to define a globally consistent territorial hierarchy, and maybe country (P17) isn't an optimal property to look for, but rather located in the administrative territorial entity (P131)? Or a well-defined combination of both. Keep in mind, the purpose of this hierarchy isn't merely to identify the relevant time zone, but also some of the other properties I mentioned, like jurisdiction or electrical power standard. For some of those, you might even have to go down to the level of individual buildings or vehicles, such as the jurisdiction of an embassy, the currency used onboard a cross-border cruising ship, or the electrical standard of a hotel or a research facility. Or, if we ignore the notability criterion for the sake of example, the DST scheme applied by the family of my secondary school biology teacher several years before Sweden officially introduced daylight savings time in 1980...
Now, this territorial hierarchy model is something I will have to discuss elsewhere, but I wanted to mention it here since it seems highly relevant to the deployment of any new time zone or DST scheme property. I find it a bit ironic that the PRC, which I'm told officially applies the same time zone throughout the country, tops my list with more than 700,000 time zone claims. I actually believe we could manage with fewer than 10,000 claims for the entire world, but it will take a lot of planning and robot maintenance before we have reached that point. At which time you should be able to run a single ?place wdt:P421 ?zone query to obtain a "minimal" time zone map and fact sheet for the world without hitting a timeout!
And again, before creating a DST scheme property, I think we should definitely look into what is available from IANA for use in Wikidata. I simply haven't had time to look; I came here merely to ask why Sweden is littered with 6,127 mutually redundant time zone claims and whether we will have to deploy another robot to clean them up as soon as EU members agree to drop the DST practice. And I first thought stating the same highest point (P610) for two coextensive or overlapping territories was overdoing it... --SM5POR (talk) 09:16, 6 July 2020 (UTC)[reply]
@SM5POR: I understand what you are aiming at, but the argument of redundancy is not 100 percent clear to me.
Simple example: As you mention, there is also country (P17) in every item of a city in the US. This would not be necessary, as there is located in the administrative territorial entity (P131) and that item has a claim about country (P17), so all the statements of country (P17) in every city (and county) are redundant. Removing these redundant statements would be a very hierarchic approach, and while there are good arguments for that, there are good counter-arguments as well. (Your SPARQL Query would not have worked in this way without relying on the fact that all cities/entities contain a country (P17)-statement.)
I came here because in the German Wikipedia, we are currently trying to compare our Time Zone-Statements (and preferably also the DST-statements) of our infoboxes to the data on Wikidata. This works well for other properties (population, land area, ...) but not for the time zone. Of course, with some Lua it would be possible to retrieve the data from either city or county or state item, but to me it would be reasonable to have this information in every item of a city/town/village and so on.
I also understand your point with Sweden, as all the places have the same Time Zone statement. Still, this helps to find all places that are in one specific time zone, independent of the country (I know, this could also be found with the hierarchic approach, but not as easy).
On the other hand, I see that there are certain statements that are not reasonable in every place item, you mentioned a few (currency etc.). However, these are statements that are expected to be identical nation-wide, while there are plenty of countries with different time zones and a clear link between place and time zone. You do not have this for currency, plug shape etc.
Therefore, I still see good arguments to use Time Zone statements on place (city/town/village) basis. If a whole country such as Sweden changed the Time Zone (or DST scheme), it would be an easy bot task to change all the affected statements, and changes of DST schemes are still quite rare in the world. Yellowcard (talk) 09:40, 6 July 2020 (UTC)[reply]
@Yellowcard: For the sake of other editors concerned with the geographic ontology and related properties, I'd prefer not to dig deeper into those details here. I'm not very familiar with the specific Infobox issues you refer to, or why time zones alone are a problem there, but I would question your apparent assertion that the other properties I mentioned can all be resolved at the national level (I even gave a few examples when they cannot, such as diplomatic representations and cross-border commerce). The reason I questioned the use of country (P17) is that it's not exclusively used on geographic entities like located in the administrative territorial entity (P131) is. There is also the issue of which properties are normally additive on a local level (like currency used or languages spoken) and which are mutually exclusive (like jurisdiction or what side of the road to drive on). But again, let's not take that discussion here.
In any case, I'm not saying we should disallow assigning time zones to cities; I just want to make it unnecessary in most cases, to trim down the total number of statements required to correctly represent all the relevant facts of the world around us. It simply doesn't scale to replicate a geography-related property, that can take one of essentially 24 distinct values, onto millions of individual localities just because time zone boundaries don't align perfectly with national ones. And if time zones pose a specific problem in Infoboxes that doesn't appear with other geographic properties, I believe that is a problem with the current implementation only, not with time zones as a commercial and social concept. There is a reason they are called 'zones' in the first place; they are not randomly chosen attributes but at least approximately related to longitude. If the robots running around updating all the locality items know how to determine the correct timezone in each case, you can apply that same heuristic also when retrieving the information. Or are you saying the procedure is so computationally expensive that it makes sense to precompute those time zone values and assign them to every significant locality years in advance? Then optimize Wikidata's cache manager to handle those queries as well (I believe it does that already). --SM5POR (talk) 11:05, 6 July 2020 (UTC)[reply]
@SM5POR: I do not understand your argument of 24 distinct values for millions of items. More extreme, there is mainly 2 genders, and still all items of a person have a statement about the gender. Time Zones are quite an individual scheme, and the deeper analysis of the situation in North America by ArthurPSmith describes the problem very well. You cannot simply draw a solid line from North to South to determine the Time Zone, the scheme is a lot more complex. And again, every city/village has a statement that it is in the United States via country (P17) and a statement of the state via located in the administrative territorial entity (P131). There is sometimes redundancy where it makes sense, and when there is redundancy about the country, I do not see a problem about redundancy in the time zone as this is more complex.
All in all, I still see more advantages to have the statement about the time zone on city/village level for countries that have more than one time zone; and probably, to stay consistent, for all cities/places worldwide on city/village level. The opposite would be that we need the time zone statement sometimes on city/village level (when the county has two time zones), sometimes on county level (when the state has two time zones) and sometimes on state level (when the state has only one time zone). To me, this does not seem very plausible and intuitive. But how can me move forward now? And this is only the first question, still not answered my original one regarding the DST ... :-) Maybe we can get the input/opinions from more users, but where to ask? Is there something comparable to "WikiProjects" here on Wikidata?
Best regards, Yellowcard (talk) 22:26, 6 July 2020 (UTC)[reply]
 Comment As far as US and Canada go, most US states are single time-zones, but there are many that are not: Alaska, Arizona, Florida, Idaho, Indiana, Kentucky, Michigan, Nebraska, North Dakota, Oregon, South Dakota, Tennessee and Texas all have 2 different zones for at least part of the year. In Canada, about half the provinces and territories have multiple time zones: British Columbia, Newfoundland and Labrador, Ontario, Quebec and Saskatchewan all use 2 zones, and Nunavut uses 3. So "county" or "city/town"-level zone definitions are probably needed for at least those states and provinces. ArthurPSmith (talk) 19:45, 6 July 2020 (UTC)[reply]
@Yellowcard, SM5POR: Some time zones include a full year-round valid definition including DST - this is part of the IANA timezone definitions, see for example America/Los_Angeles (Q4742667). And yes there are Wikiprojects here on Wikdiata - see Wikidata:WikiProjects. ArthurPSmith (talk) 14:00, 7 July 2020 (UTC)[reply]

@Yellowcard, SM5POR, ArthurPSmith: The individual UTC offsets could be kept at the IANA time zone item, and on individual places one only states the IANA time zone, this would cut down the number of statements and allows for easy addition of information backward to 1970. See Wikidata:Property proposal/located in IANA time zone. GeoGQL (talk) 22:02, 5 May 2023 (UTC)[reply]

Transitive instead of data duplication[edit]

Hi folks, I was talking with User:Piastu about the data duplication we currently have with this property. A timezone is generally connected to an administrative region and applies to everything located in that administrative region. So for example if North Holland (Q701) is in UTC+01:00 (Q6655), than Haarlem (Q9920) is in the same zone because Haarlem (Q9920) has located in the administrative territorial entity (P131) set to North Holland (Q701) (the inconsistent data is out of scope here, but should probably get sorted before doing any mass edits). I propose we start using this transitive relation. That means cleaning up the data and updating downstream usage (like an infobox) to make use of it.

I would propose to add the located in time zone (P421) to the highest administrative region that is in a single timezone (including Summer Time). In some cases like Germany (Q183) this will just be the country. For practical purposes you might decide to add it to one lower level if that doesn't make the data explode. If you hit the applies to part qualified statements, you know you're to high in the tree and it's no longer transitive.

We should probably document somewhere per country how to model it because it's not always obvious. When agreement we have agreement for a country, the data can be cleaned up. What do you think? Multichill (talk) 11:44, 14 May 2022 (UTC)[reply]

@Yellowcard, SM5POR, ArthurPSmith: ^ ? Multichill (talk) 15:22, 15 May 2022 (UTC)[reply]
It's not v.clear what problem you are trying to solve. You could, presumably, make exactly the same argument for P17. You frame this as data duplication, but it doesn't fit my understanding of that term; it's more akin to denormalisation. You speak of 'cleaning' the data; but that's not what you're proposing ... you are proposing to change the model for timezone data storage, and selling that changed model as a cleaning exercise.
So, right now, I very much oppose your plan, which seems at best ill-considered. --Tagishsimon (talk) 22:04, 15 May 2022 (UTC)[reply]
I like the idea and it makes sense to me. However, for usecases such as infoboxes, we need to be aware that it will be difficult to retrieve this data. Let's stay with the United States as an example: For many states, a statement about the timezone in the state item would be sufficient and would cover all places within this state, for example California. However, as ArthurPSmith has pointed out in the thread above, there are some states where it is not that eazy, for example Arizona. Here we need to break down to county or place level. For infoboxes in place articles, they need to check then the item of the place, county and state (or even more in more hierarchic states?) whether there is a timezone statement. This is complicated and expensive.
Then you say "For practical purposes you might decide to add it to one lower level if that doesn't make the data explode.", but isn't that exactly the current case what you would like to "clean up"? With the practical use in mind, I would just add it to any place item for countries with different time zones (Germany might not be the ideal example, as one time zone statement in Germany (Q183) covers all single entities in Germany).
The realization in Quebec (Q176) is not ideal, I agree. And I also support the idea to document the procedure / data model per country, such as: Germany -> no individual time zone statements is sub entities, USA -> time zone statement in each place/county item, Netherlands -> ...
Best regards, Yellowcard (talk) 06:25, 16 May 2022 (UTC)[reply]
It definitely looks like some cleanup would be helpful particularly on the higher-level administrative entities that have multiple values for this property, we should be clear on how that should be modeled. On the other hand I don't see a lot of harm in attaching timezones to lower-level entities even if that may be redundant. But if in some countries it doesn't make sense to do that then that's ok too. I would point out that timezone and higher-level administrative location may both change over time (or be disputed) so there are some complications associated with current vs historical entries also. ArthurPSmith (talk) 15:12, 16 May 2022 (UTC)[reply]
I am very much in favor of this idea. However, it's one I've thought about and worked on, and it's surprisingly tricky.
For one thing, not all time zone boundaries correspond to administrative boundaries. For example, Malheur County (Q495414) is mostly on Mountain time, but the southern part of it is on Pacific Time, with no administrative boundary to tie the time zone boundary to.
Perhaps worse, administrative regions tend not to form perfect hierarchies. There was big discussion a while back about a proposal to tinker with the administrative region hierarchy, in part to straighten out the confusing situation in Atlanta (Q23556).
But the current way we're using located in time zone (P421) is, yes, quite ridiculous.
If there's any interest in pursuing this idea or something like it, I can offer a data set I've created containing the largest administrative regions worldwide which are all on the same time zone. —scs (talk) 17:17, 19 May 2022 (UTC)[reply]
This property is transitive IRL so the modelling of it should be transitive too. It's just silly to add timezone claims to cities. The only drawback I can think of is that it's inconvenient/inefficient to parse administrative regions, so there ought to be a predictable fallback, in other words countries/states should perhaps be guaranteed to have this property even if it contains multiple timezones. Infrastruktur (talk) 21:23, 1 May 2023 (UTC)[reply]
Since there is already special treatment of "country", country could be a logical level. GeoGQL (talk) 21:54, 5 May 2023 (UTC)[reply]

I see another issue. Germany seems to be an easy case if only we look to Germany today. However, midday is twelve o'clock, it is the moment when the sun is on her highest point and the shadow on its shortest. Well, more scientificalle, the problem is, that most people do not differ between local mean time (Q219919) and Solar time (Q192854). The latter even does not seem to have articles in other languages than German. But it is important for some religions for dertermine when it is time for prayers. Otherwise bevor the advent of railway each village had its own time. Historically it might be necessary to differ times on smaller entities the countries.

Wikidata:Property proposal/located in IANA time zone[edit]

You might be interested in Wikidata:Property proposal/located in IANA time zone. GeoGQL (talk) 21:55, 5 May 2023 (UTC)[reply]

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