[tz] Preparing to fork tzdb

[dpatte]

I strongly agree with Stephen here. Every iso country needs at least one slot in the db for their own history back to lmt. Applications have a need for this type of historical data. Should this data be captured in tz, or a fork?Sent from my Galaxy
-------- Original message --------From: Stephen Colebourne via tz <tz at iana.org> Date: 2021-09-21  15:34  (GMT-05:00) To: Time zone mailing list <tz at iana.org> Subject: Re: [tz] Preparing to fork tzdb On Tue, 21 Sept 2021 at 17:48, Paul Eggert via tz <tz at iana.org> wrote:> This disagreement is not about whether the data in question are> available; it's only about which file they're in. Nothing is being> "wiped out" or refused.It is about more than that. The current unreleased state of tzdb isthat it favours some countries over others, such as Germany overSweden/Norway. It does this to a much greater extent than before. Frommy perspective, that is the root of the problem here.> I think this greatly underestimate the effort to do a complete job. We'd> eventually need thousands of Zones.I would imagine that most readers of this list would not wantthousands of zones. The goal of including every time-zone that hasever been is a straw man.I'm perfectly happy with the post-1970 rule for determining what IDswe have so long as it results in one ID per ISO country. In addition,at least one ID per ISO country is entitled to have full history backto LMT, **even if it is innaccurate**.>  [I] am UCLA teachingprofessor who has institutional obligations in the areas of equity,diversity and inclusion...> merely going back to2021a's setup is not something we can or should do, on equity grounds.The patch makes the equity/diversity/inclusion position of tzdb far,far worse. Appreciating this is the first step necessary to resolvingthis.Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210921/a19c2cb4/attachment.html>