On Sun, 6 Jun 2021, Stephen Colebourne via tz wrote:
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.
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).
2) Negative DST Negative DST in the source files continues to be a problem, but we should address other issues first.
When I first highlighted this Irish case (https://mm.icann.org/pipermail/tz/2017-December/025621.html), it was never my intention that the tz data was changed to negative DST - I was originally only pointing out that IST isn't only Iran Standard Time, but also Irish Standard Time. I don't mind how it is recorded, as long as it produces the right output (in the form of transitions).
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.
PHP's implementation *does* know which ones are deprecated, by marking the tzids that are not listed in code/zone.tab as such. It does not however offer what the replacement is. <snip>
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.
This proposal seems very sensible to me, with perhaps the exception as what to pick for the "before LMT" offset. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug