[tz] TZDB use cases

[Paul Eggert]

On 10/3/21 1:58 PM, Michael H Deckers via tz wrote:

>      From the viewpoint of SQL database system providers, one cannot
>      "merge" Europe/Oslo with Europe/Berlin because tzdb does not
>      (and can not) guarantee that they remain the equal in the
>      future.

That's OK and there's longstanding precedent for that sort of thing, as 
database users should not "merge" Europe/Vatican to Europe/Rome for the 
same reason, even though the former is a Link and the latter a Zone in 
tzdb. This issue predates and is largely independent of whether 
out-of-scope pre-1970 Zones should be merged within tzdb itself.


>      For instance,
>      the dst bit used to indicate "summer time" for about 20 years,
>      but since 2018a, the dst bit could also indicate winter time

If this is talking about so-called "negative DST" where the UT offset 
with is_dst is less than the UT offset without, then "winter time" is in 
general a misnomer as the phenomenon can occur in summer (e.g., Morocco) 
as well as in winter (e.g., Ireland). And negative DST has been been 
required by POSIX and supported by tzcode for decades; the only new 
thing circa 2018 is that this longstanding feature began to be used in 
tzdata.


>      it is not even true that the two time scales
>      always agree after 1970, although most people seem to believe
>      otherwise.

If there are counterexamples please suggest fixes, preferably in 'git 
format-patch' form. Although 'backzone' is documented to be less 
reliable, we're certainly open to fixes from the community.