[tz] suggestion: split "backward" into "backward" and "deprecated"

[J William Piggott]

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.
>