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.