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