Dropping coordinates from zone1970.tab?
Hi, With the recent changes, geographically distant locations share the same timezone and the same coordinates in the zone1970.tab file. For instance Antarctica/Syowa is a link to Asia/Riyadh and appear with the same coordinates in the zone1970.tab file, while they are more than 10000 km apart. The zone1970.tab says: "This table is intended as an aid for users, to help them select timezones appropriate for their practical needs". I have the impression that the coordinates in that table do not anymore aid users to select appropriate timezones, so I wonder if they should just get dropped. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On Sep 29, 2021, at 1:22 PM, Aurelien Jarno via tz <tz@iana.org> wrote:
The zone1970.tab says: "This table is intended as an aid for users, to help them select timezones appropriate for their practical needs". I have the impression that the coordinates in that table do not anymore aid users to select appropriate timezones,
Did they ever do so? The coordinates for the tzdb region in which I live point to a random location on 1st street in Los Angeles, which is over 400 km from where I live, and is far from where the vast majority of people in the America/Los_Angeles region live. (It's not all that near where many people in the *Los Angeles metropolitan area* live.)
On 2021-09-29 13:35, Guy Harris wrote:
On Sep 29, 2021, at 1:22 PM, Aurelien Jarno via tz <tz@iana.org> wrote:
The zone1970.tab says: "This table is intended as an aid for users, to help them select timezones appropriate for their practical needs". I have the impression that the coordinates in that table do not anymore aid users to select appropriate timezones,
Did they ever do so? The coordinates for the tzdb region in which I live point to a random location on 1st street in Los Angeles, which is over 400 km from where I live, and is far from where the vast majority of people in the America/Los_Angeles region live. (It's not all that near where many people in the *Los Angeles metropolitan area* live.)
If you consider a world map to select the timezone, with each timezone represented by a circle from the coordinates in the zone1970.tab, you will find the America/Los_Angeles close to where you live, and it would be natural to select it. We are talking of 400km at the scale of a world map. In the example I gave, we are talking about more than 10000 km from South to North, roughly half of the map. I am not sure users will have the idea to look so far for their timezone. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On 9/29/21 14:26, Aurelien Jarno via tz wrote:
If you consider a world map to select the timezone, with each timezone represented by a circle from the coordinates in the zone1970.tab
zone1970.tab has never been intended as a "nice" geographical interface in that sense. At the end of this email is a tzselect sample session (using 2021a, so more-recent changes are irrelevant) that uses nearest-neighbor from the South Pole, employing zone1970.tab's data. As you can see, tzselect prompts with ten nearest neighbors that are all incorrect because the correct answer is Pacific/Auckland, which is nearly 6,000 km away. Akthough I'm sure this way of using tzselect could be improved a bit, it's hardly worth the trouble as almost nobody uses it this way (the few people who use tzselect, typically don't take choice "10)" below). Instead of tzselect, most people use maps based on data that are proprietary (or cited in tz-link.html) and are outside tzdb's scope. These maps commonly depict some tall skinny timezones one of which could easily incorporate both Auckland and the South Pole (such a timezone need not be visually contiguous), and this is what I suggest for user-facing interfaces based on distances. Riyadh and Syowa can be handled similarly. ----- $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) TZ - I want to specify the timezone using the Posix TZ format. #? 10 Please enter coordinates in ISO 6709 notation. For example, +4042-07403 stands for 40 degrees 42 minutes north, 74 degrees 3 minutes west. -9000+00000 Please select one of the following timezones, echo listed roughly in increasing order of distance from -9000+00000. 1) Antarctica - Vostok 6) Antarctica - Rothera 2) Antarctica - Troll 7) Antarctica - Dumont-d'Urville 3) Antarctica - Syowa 8) Antarctica - Casey 4) Antarctica - Davis 9) Antarctica - Palmer 5) Antarctica - Mawson 10) Argentina - Tierra del Fuego (TF) #?
On 2021-09-29 14:50, Paul Eggert via tz wrote:
On 9/29/21 14:26, Aurelien Jarno via tz wrote:
If you consider a world map to select the timezone, with each timezone represented by a circle from the coordinates in the zone1970.tab
zone1970.tab has never been intended as a "nice" geographical interface in that sense. At the end of this email is a tzselect sample session (using 2021a, so more-recent changes are irrelevant) that uses nearest-neighbor from the South Pole, employing zone1970.tab's data. As you can see, tzselect prompts with ten nearest neighbors that are all incorrect because the correct answer is Pacific/Auckland, which is nearly 6,000 km away.
Akthough I'm sure this way of using tzselect could be improved a bit, it's hardly worth the trouble as almost nobody uses it this way (the few people who use tzselect, typically don't take choice "10)" below). Instead of tzselect, most people use maps based on data that are proprietary (or cited in tz-link.html) and are outside tzdb's scope. These maps commonly depict some tall skinny timezones one of which could easily incorporate both Auckland and the South Pole (such a timezone need not be visually contiguous), and this is what I suggest for user-facing interfaces based on distances. Riyadh and Syowa can be handled similarly.
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually. While timezones concept might sometimes be difficult to end users, they are usually aware if a city near to their location "has the same time or not". I took the example of Antarctica/Syowa and Asia/Riyadh as those locations are very far, but with tzdata 2021b you can find other examples in the Carribean region, for instance Nassau which is a link to Toronto. The other alternative for end users to select a timezone, is to present them with all timezones matching their country (using ISO 3166). This is getting more and more difficult with timezone being merged in zone1970.tab, you end-up showing timezones that look unrelated for end users. Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab, but that file is currently deprecated in favor of zone1970.tab. I guess it will just get removed when the process of merging timezone is finished. Undeprecating it would solve all those issues. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On 9/30/21 12:51 AM, Aurelien Jarno via tz wrote:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
Sure, but that's straightforward to do visually regardless of timezone shape, even if the timezone is non-contiguous. A user points to a spot on the map, and the system picks the timezone containing that location (it can highlight the whole timezone region as the user points to a city, as visual feedback). A user who points to the South Pole should get Pacific/Auckland or equivalent even though Auckland is 6,000 km away. Again, this is not a new issue, as the South Pole has been merged with Pacific/Auckland for many years in tzdb.
Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab
Not all info, surely. Timezone boundaries are not there. Nor is internationalization. A lot of stuff is missing.
but that file is currently deprecated in favor of zone1970.tab. I guess it will just get removed when the process of merging timezone is finished.
That file has been deprecated for ages as its function is unclear, and it seems to be used differently by different downstream users. However, I was not planning to remove it even after merges are done, given that it's still being used.
On 2021-09-30 01:06, Paul Eggert wrote:
On 9/30/21 12:51 AM, Aurelien Jarno via tz wrote:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
Sure, but that's straightforward to do visually regardless of timezone shape, even if the timezone is non-contiguous. A user points to a spot on the map, and the system picks the timezone containing that location (it can highlight the whole timezone region as the user points to a city, as visual feedback). A user who points to the South Pole should get Pacific/Auckland or equivalent even though Auckland is 6,000 km away. Again, this is not a new issue, as the South Pole has been merged with Pacific/Auckland for many years in tzdb.
Again the problem is not about automatically selecting the timezone when clicking on a random location, but clicking on those cities. Among others Antarctica/Syowa or America/Nassau can't be shown anymore on a map. End users will have to select Ryhad and Toronto
Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab
Not all info, surely. Timezone boundaries are not there. Nor is internationalization. A lot of stuff is missing.
Timezone boundaries are not needed. Internationalization can be done at a different layer.
but that file is currently deprecated in favor of zone1970.tab. I guess it will just get removed when the process of merging timezone is finished.
That file has been deprecated for ages as its function is unclear, and it seems to be used differently by different downstream users. However, I was not planning to remove it even after merges are done, given that it's still being used.
It has been deprecated for a bit more than 2 years. And as you said it is used by different downstream users. That said for me deprecated means that it will get removed at some point and that those downstream users have to find another database instead. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On Sep 30, 2021, at 1:34 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
Again the problem is not about automatically selecting the timezone when clicking on a random location, but clicking on those cities. Among others Antarctica/Syowa or America/Nassau can't be shown anymore on a map.
"Antarctica/Syowa" and "Asia/Riyadh" are regions on the map, not points on the map, and if you show a map in which every tzdb region is shown sedately, both of those regions would be shown in a map based on 2021b, because they're the same region, so, if one would be shown, the other would be shown as well. The same applies to "America/Nassau" and "America/Toronto".
End users will have to select Ryhad and Toronto
Meaning "end users will have to select the region corresponding to Asia/Riyadh and the region corresponding to America/Toronto". If a map showing tzdb regions is big enough to show cities, it would show Toronto and Montreal and Ottawa in the America/Toronto region. It would also show Nassau, although the region probably would be shown as two (or more) separate areas. Alternatively, on a system that supports graphical user interfaces, you could show a world map that shows the current "time zone" (in the traditional sense, not in the tzdb region sense) and that lets you dig that zone east or west to select a zone - and then lets you click a location within the zone to choose which particular tzdb region you want. It could also provide a box into which to type the name of a city (*NOT* necessarily a city whose name appears in the name of a Zone or Link in the tzdb!). To see an example of this, either: 1) sit in front of a machine running macOS, pop up System Preferences, select "Date & Time", click the padlock if it's locked and enter an appropriate password, and un-check "Set time zone automatically using current location" (so that you can manipulate the map) or 2) sit in front of a machine running a sufficiently recent version of Ubuntu with the standard GNOME GUI (18.04 and 20.04 work, for example), click "Activities", enter "time zone", select "Date & Time", turn off "Automatic time zone" if it's on, and click "Time Zone". There may be others (I have not, for example, checked any recent Ubuntu releases to see what their KDE UI does, nor have I checked any Fedora release).
On 2021-09-30 02:14, Guy Harris wrote:
On Sep 30, 2021, at 1:34 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
Again the problem is not about automatically selecting the timezone when clicking on a random location, but clicking on those cities. Among others Antarctica/Syowa or America/Nassau can't be shown anymore on a map.
"Antarctica/Syowa" and "Asia/Riyadh" are regions on the map, not points on the map.
Thanks, that is the demonstration that those coordinates in the zone1970.tab file (i.e. points and not regions) are totally useless and should just be dropped. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On Sep 30, 2021, at 2:18 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
On 2021-09-30 02:14, Guy Harris wrote:
On Sep 30, 2021, at 1:34 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
Again the problem is not about automatically selecting the timezone when clicking on a random location, but clicking on those cities. Among others Antarctica/Syowa or America/Nassau can't be shown anymore on a map.
"Antarctica/Syowa" and "Asia/Riyadh" are regions on the map, not points on the map.
Thanks, that is the demonstration that those coordinates in the zone1970.tab file (i.e. points and not regions) are totally useless and should just be dropped.
Good, because that's exactly what I think should happen (as I indicated in an earlier message)!
On Sep 30, 2021, at 12:51 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
"Cities linked to the timezones" as in "the cities whose names appear in the tzids of the regions", or as in "cities located within the regions"? The latter sounds far more useful to users than the former, as that way the end user can look for the city nearest to them, *even if that city doesn't happen to be the one used in the tzid for their region*. It would also let them type in the name of a city near them to specify the region they're in (as long as the city isn't both near them *and* in a different zone.)
While timezones concept might sometimes be difficult to end users, they are usually aware if a city near to their location "has the same time or not".
"Has the same time" as what? Presumably not the city whose name appears in the tzid of the region, as users shouldn't have to be aware of tzids.
Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab,
zone.tab has the boundaries of tzdb regions as well as the names of sufficiently significant cities in each region? I don't see the names of the two largest cities near me in that file, much less the name of the smaller city in which I live, so I don't see any way to construct a nice way to select a timezone from that data.
On 2021-09-30 01:28, Guy Harris wrote:
On Sep 30, 2021, at 12:51 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
"Cities linked to the timezones" as in "the cities whose names appear in the tzids of the regions", or as in "cities located within the regions"?
The latter sounds far more useful to users than the former, as that way the end user can look for the city nearest to them, *even if that city doesn't happen to be the one used in the tzid for their region*. It would also let them type in the name of a city near them to specify the region they're in (as long as the city isn't both near them *and* in a different zone.)
I am talking about the "the cities whose names appear in the tzids of the regions", independently if they appear as tzid or as a link.
While timezones concept might sometimes be difficult to end users, they are usually aware if a city near to their location "has the same time or not".
"Has the same time" as what? Presumably not the city whose name appears in the tzid of the region, as users shouldn't have to be aware of tzids.
I am putting myself in the end user perspective. They do not know a lot about timezones, however they usually know if the nearby cities from their country follow the same rules regarding the time as the place they live.
Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab,
zone.tab has the boundaries of tzdb regions as well as the names of sufficiently significant cities in each region? I don't see the names of the two largest cities near me in that file, much less the name of the smaller city in which I live, so I don't see any way to construct a nice way to select a timezone from that data.
Again you do not need the boundaries. Do you see the country where you live in that file, and at least one city? Unless you live in Bouvet Island or Heard Island and McDonald Islands, two uninhabited regions, that should be the case. This means that you can be presented with a map with cities to pick-up. Yes you need some clue to pick-up the right one, but far less than when you have to pick-up Toronto when living in Bahamas. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
On Sep 30, 2021, at 1:57 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
On 2021-09-30 01:28, Guy Harris wrote:
On Sep 30, 2021, at 12:51 AM, Aurelien Jarno via tz <tz@iana.org> wrote:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
"Cities linked to the timezones" as in "the cities whose names appear in the tzids of the regions", or as in "cities located within the regions"?
The latter sounds far more useful to users than the former, as that way the end user can look for the city nearest to them, *even if that city doesn't happen to be the one used in the tzid for their region*. It would also let them type in the name of a city near them to specify the region they're in (as long as the city isn't both near them *and* in a different zone.)
I am talking about the "the cities whose names appear in the tzids of the regions", independently if they appear as tzid or as a link.
End users should neither have to know or care about tzids.
While timezones concept might sometimes be difficult to end users, they are usually aware if a city near to their location "has the same time or not".
"Has the same time" as what? Presumably not the city whose name appears in the tzid of the region, as users shouldn't have to be aware of tzids.
I am putting myself in the end user perspective. They do not know a lot about timezones, however they usually know if the nearby cities from their country follow the same rules regarding the time as the place they live.
Anybody who puts themself in the end user perspective should start by saying "how can I let the user select a tzdb region without having to know anything about tzids?" For a general-purpose computer with a GUI, both Apple and Ubuntu have done so; see the mail I sent before this one.
Note that all the information for providing nice ways to select a timezone for end-users is available in zone.tab,
zone.tab has the boundaries of tzdb regions as well as the names of sufficiently significant cities in each region? I don't see the names of the two largest cities near me in that file, much less the name of the smaller city in which I live, so I don't see any way to construct a nice way to select a timezone from that data.
Again you do not need the boundaries. Do you see the country where you live in that file,
Yes, but I don't see the city in which I live.
and at least one city? Unless you live in Bouvet Island or Heard Island and McDonald Islands, two uninhabited regions, that should be the case. This means that you can be presented with a map with cities to pick-up.
Yes, I can be presented with a map that I can use to indicate to the computer what tzdb region I want. On my host machine, I can do so just by popping up System Preferences, selecting "Date & Time", clicking the padlock if it's locked and entering my password (as my account has administrator privileges), and un-checking "Set time zone automatically using current location". On my Ubuntu 18.04 and 20.04 guest machines, I can do so by just clicking "Activities", entering "time zone", selecting "Date & Time", turning off "Automatic time zone" if it's on (which it isn't, on those machines), and click "Time Zone".
Yes you need some clue to pick-up the right one, but far less than when you have to pick-up Toronto when living in Bahamas.
If you're showing a map with cities, it should show Nassau, because that's a significant city; you shouldn't restrict yourself to cities with names that happen to appear in the name of a tzdb Zone.
On 9/30/21 1:57 AM, Aurelien Jarno via tz wrote:
This means that you can be presented with a map with cities to pick-up.
If I understand you correctly, you're not concerned about tzselect (which is text-only). Instead, you're concerned about a graphical user interface that shows a map of cities without showing timezone regions, or perhaps shows timezone regions that don't match the actual (but undocumented) tzdb regions well. I would say that such UIs have always been problematic, as inaccurate or missing region boundaries can make such maps difficult to use. Although this has long been true (as witness the South Pole example), I don't see why it means we should drop coordinates from zone1970.tab (coordinates that tzselect uses and which graphical UIs can also use); all it means is that those maps and/or UIs could use improvements.
Aurelien Jarno via tz said:
The point is not about choosing a timezone from a location, but rather being able to show the cities linked to the timezones on a map so that end users can pickup their timezone visually.
If you're doing that, you should be showing the area on the map, not a circle around the most-populous city.
The other alternative for end users to select a timezone, is to present them with all timezones matching their country (using ISO 3166).
A third option is to ask them "what time is it right now?" and then list (or show on a map) all the zones that have the same offset. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
If you want to find a tzdb region based on your current location, it's best to, for example, use https://github.com/evansiroky/timezone-boundary-builder and perhaps some of the libraries it mentions.
Aurelien Jarno via tz said:
If you consider a world map to select the timezone, with each timezone represented by a circle from the coordinates in the zone1970.tab, you will find the America/Los_Angeles close to where you live, and it would be natural to select it. We are talking of 400km at the scale of a world map.
There are at least two time zone cities within 400 km of where I live and another at 406 km. For much of this country (probably more than half by area), the wrong city is closer than the correct one. I can't believe this is the only place with that problem. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
participants (4)
-
Aurelien Jarno -
Clive D.W. Feather -
Guy Harris -
Paul Eggert