On Mon, 4 May 2020, Andrew Gierth wrote: ... >8
Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated".
... >8
(One further exception should be made: the link from Etc/UTC to UTC is
I tried to get UTC added to zone.tab back on 9 Mar 2016; but received a lot of push back. Everyone seemed to be hung up on the use-case definition that UTC is an enigma, existing everywhere and nowhere at the same time. Heads exploded at the thought of UTC having a geographic connection, which it does. Enumerating that connection in no way inhibits the enigma use-case, IMO. It is incomprehensible to me that a database built around a single reference, makes that reference unreachable from within, for lack of better a term, its API. There are many projects, both hardware and software, that use zone.tab as the Time Zone Database API. For these projects, if it's not in zone.tab it does not exist. For example, in my GPS hardware I'm forced to use Reykjavik for UTC. The geographic tie is just a API lookup index, any zone can be used at any location. If I'm in Tokyo, I can still use the New York zone, even though that zone has a North American geographic tie. UTC having a geographic tie doesn't in anyway inhibit its global use. Another complaint was that a single locale is not a zone. The DB already contains single point 'zones' in Antarctica, which are in zone.tab. ... >8
-- Andrew.