[tz] TZDB use cases
Paul Eggert
eggert at cs.ucla.edu
Mon Oct 4 01:45:51 UTC 2021
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.
More information about the tz
mailing list