[tz] What data should TZDB offer?

[Guy Harris]

On Jun 7, 2021, at 1:25 AM, Derick Rethans via tz <tz at iana.org> wrote:

> I'm not sure whether this is a solution that you can universally use. 
> For example Amsterdam's rules in the 1920s specifically used 
> UTC+1172/+4772. Having the now standard time "+3600" before that makes 
> less sense than continuing to keep LMT (which also happens to be +1172).

Hopefully nobody assumes that, prior to 1835, Europe/Amsterdam, in the backzone version of the database, refers to any part of the Europe/Amsterdam other than Amsterdam itself (or some subregion thereof).

(The same applies for all other tzdb regions that begin with an LMT value.)

Note that theory.html says "don't do that":

	In short, many, perhaps most, of the tz database's pre-1970 and future timestamps are either wrong or misleading. Any attempt to pass the tz database off as the definition of time should be unacceptable to anybody who cares about the facts. In particular, the tz database's LMT offsets should not be considered meaningful, and should not prompt creation of timezones merely because two locations differ in LMT or transitioned to standard time at different dates.

> I was 
> originally only pointing out that IST isn't only Iran Standard Time, but 
> also Irish Standard Time.

Hopefully nobody using any APIs that return time zone abbreviations is assuming that those abbreviations can, in the general case, be used to determine what time zone you're in - i.e., display them to the user, but don't attempt to process them to infer any information unless you know that they come from a limited set of tzdb regions in which no two regions ever have the same abbreviations.