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