[tz] What data should TZDB offer?

Derick Rethans tz at derickrethans.nl
Mon Jun 7 08:25:52 UTC 2021

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.


> 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.


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

More information about the tz mailing list