On 5/11/21 5:32 AM, Michael H Deckers wrote:
Rather, the corresponding geographic coordinates in zone.tab are no longer connected with the timezone name, only with an ISO country code.
I wouldn't put it that way. In zone.tab, a line's geographic coordinates are connected with both the country code and the timezone name. That is, the coordinates identify a location that is both (a) in the country, and (b) has clocks that have agreed with the timezone since 1970.
The same holds for several proposed lines in zone1070.tab such as AQ,KW,SA,YE +2438+04643 Etc/GMT-3 Arabia, Syowa What are these geographical coordinates supposed to indicate?
They indicate a major location within the designated area. This is the same as the non-Etc lines in zone1970.tab, and it's the same role they play in zone.tab.
One of the successful design choices of the tzdb database was to identify timezones by locations (rather than by areas or countries), so that location names and location coordinates are equivalent means of identifying timezones of locations. Is this still true?
That depends on what one means by "equivalent" :-). Timezone names like Etc/GMT never identified single locations all that well. An alternative strategy to what's proposed in the patch, is to keep a single location-based Zone in place of each Etc/* name that the patch uses. For example, where the patch proposes making several names (Asia/Dubai, Asia/Muscat, Indian/Mahe, Indian/Reunion) backward-compatibility aliases for Etc/GMT-4, we could instead keep Asia/Dubai (the most-populous location) as a Zone, and have the other names be backward-compatibility aliases for Asia/Dubai. In the long run this approach would be a bit more work than what the patch proposes, as it'd mean we should continue to maintain out-of-scope (pre-1970) data for Asia/Dubai, Asia/Bangkok, etc. The main advantage of it would be avoiding Etc/* names as link targets and in zone*.tab files.