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

[Brian Inglis]

On 2020-05-04 19:58, Paul Gilmartin via tz wrote:
> On 2020-05-04, at 18:26:22, Andrew Gierth wrote:
>> I mean that where the tzcode uses "GMT" as a default zone name or
>> abbreviation in the absence of data, FreeBSD uses "UTC" (and has since
>> 2004).
>> e.g. with no /etc/localtime file,
>> % env -u TZ date
>> Tue  5 May 2020 00:00:37 UTC
>>
>> (To the best of my knowledge there are no reference clocks available to
>> which one could synchronize in order to use a mean solar time, so your
>> argument seems to me to support this choice.)
>>  
> Do you mean mean solar time at some arbitrary precise longitude
> or mean solar time at the Prime Meridian?  If the latter, is
> interpolated UT1 a close enough approximation?:
>     https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination

No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R
has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of
UT would be required to provide mean solar time at a consistent rate.
NIST are still applying radio clock accuracy standards with ~ms precision, where
the current norm is ~us from GPS, certainly over local LAN and even over decent
remote WAN links.

The older standard is adequate for MS products which require only
watch-and-eyeball accuracy, but more systems are needing more accurate time.

[The point may be moot, as the lawyers heading the US FCC approved the junk
science from US Ligado Networks lawyers that say GNSS will not be disrupted by
their terrestrial L band transmissions.
Those disrupted will have to prove to US FCC lawyers that they were disrupted by
US Ligado Networks transmissions.
Ligado used to be LightSquared which went bankrupt when their testing proved
their transmissions would disrupt GNSS.
The FCC no longer requires tests, just sworn assertions from lawyers, if the
lawyers approve how the physics is used!]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]