[tz] What data should TZDB offer?

[Stephen Colebourne]

TZDB has seen recent difficulties due to conflicting desires and
expectations of the dataset. This is an attempt to capture some of
these:

1) LMT
LMT is confusing for many downstream users because they don't
understand the concept. Recent threads have noted queries from
Postgres users, I can attest to confusion in various Java libraries.
In fact, earlier versions of Java removed the LMT concept. I think the
time is right to properly consider an alternative to LMT. I believe we
can define an offset for each region that the region has most
typically been associated with post 1970. For example, Europe/Paris is
most associated with +01:00 since 1970. This provides the "normal
looking" offset that most users desire for the LMT period.

2) Negative DST
Negative DST in the source files continues to be a problem, but we
should address other issues first.

3) Links
At present, it is not possible to identify which region names are
deprecated (such as spelling changes) and which represent important
data. Having such a distinction would allow permanent deprecations to
be removed from some downstream systems, and would also allow
downstream systems to provide functionality to normalize IDs from old
to new in a correct and consistent way.

4) Pre-1970 history
There is general, though not compete, agreement that TZDB's main focus
is on post-1970 data. However I and others have an expectation that
pre-1970 data is retained and not be removed. I don't want to get into
a position where pre-1970 history is basically completely unreliable
relative to the name of the ID. Getting Germany's pre-1970 rules when
you have an ID for Oslo or Sweden is not acceptable. (We already have
some of that, but the recent proposal would have greatly increased the
issue. I feel that there is the potential to achieve an agreeable
solution, but it does require acceptance that full pre-1970 history is
needed for some places that have the same zone history post-1970.

5) Compatibility guarantee
Changes need to be made with more consideration of the implications of
compatibility on downstream users that do not use the makefile.

Proposal
------------
That TZDB shall adopt the principle that the main geographic files
(africa to southamerica) shall contain data with full history for
locations where zone history has differed since 1970 subject to the
minimum requirement that there is at least one full zone with history
defined for each independent country as defined by ISO-3166-1.
Dependent territories in ISO-3166-1 that are within 1/24th of the
earth circumference of another dependent territory or parent country
with the same sovereignty shall be combined if their post-1970 history
is identical.

That TZDB shall replace LMT with the offset that best represents
standard time for the location during the period 1970 to 2021.

That TZDB shall define a non-makefile mechanism, which may involve a
new file, to identify permanently deprecated IDs, such as "Turkey" or
"W-SU".

That TZDB shall offer a command line makefile flag that filters the
data to reduce the binary output where data is the same post-1970.
That consideration is given to whether this flag should erase pre-1970
history as part of it's truncation process.

That these rules shall be encoded in the theory file along with an
explicit statement of backwards compatibility.

-----
It is my belief that this proposal meets the issues expressed above
while also respecting the concerns of fairness, guidelines and
politics expressed by others. For example, TZDB would not include a
full zone with history for Kosovo until ISO-3166-1 includes it. This
provides a straightforward defence against the worst issues of
politics.

The dependent territory rules are designed to allow locations that are
close to each other in distance and sovereignty to be combined, such
as  Jersey and London. I have not analyzed how many zones of full
history can be saved by this mechanism.

I acknowledge that the above is a significant change to TZBD, but it
does more fully align TZDB with the Governmental authorities that
actually define time zones. I also believe it more closely aligns TZDB
with the expectations of downstream users.

Stephen