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

<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


More information about the tz mailing list