[tz] timezone Verschlimmbesserung

[Scott Kilpatrick]

Thanks to Tony Finch's evidence, I'm now realizing two key points that were
unclear to me as a follower of the project since only 2018.

1) In 2013, a long-adopted policy of having a Zone for each ISO 3166
country was abandoned at Paul's discretion [1], a decision that was
disputed at the time and didn't seem to have much support from others.

2) Paul's initial changes in 2013-2014 to unify zones that don't differ
post-1970, starting alphabetically with African Zones, *were indeed highly
disputed at the time.* In particular, Stephen Colebourne, who's been the
most vocal opponent of the current changes, laid out the exact same
justifications back then! As did others who are commenting today.

For examples, see threads [2-8].

If anyone is reading Paul's current justifications for these changes, one
comes away with the impression that people are only complaining now that
it's European countries' Zones being merged rather than African countries'
Zones. Paul himself wrote in his justification [9]:

> It's a bad look for us that so much concern about Norway and Sweden has
> appeared on this mailing list, even though hardly anybody seems to have
> cared about Angola and Congo. It'll be an even worse look if we ignore
> this issue weeks, months or even years after it's been made clear to us.

This description is not only demonstrably false, as the above examples
show, but indelicate and incendiary given the context -- namely, that Paul
is invoking racial and national bias to motivate the changes this time. In
another thread recently Paul wrote that "the equity issue has broadened and
is now visible outside our little community" [10]. So why give this false
and misleading impression of people's motives to those outside our little
community?

As further context for my remarks, I'd like to add that, although I'm
relatively new to the project, I have tremendous respect for Paul's
contributions to it over the decades. His long-standing practice of
providing insightful history, context, links, and pop culture examples
throughout the project files and this mailing list is directly responsible
for my own fascination with tzdb.

Best,
Scott Kilpatrick
https://typesandtimes.net

[1]
https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733e
[2] https://mm.icann.org/pipermail/tz/2013-August/019601.html
[3] https://mm.icann.org/pipermail/tz/2013-August/019593.html
[4] https://mm.icann.org/pipermail/tz/2013-August/019646.html
[5] https://mm.icann.org/pipermail/tz/2013-August/019674.html
[6] https://mm.icann.org/pipermail/tz/2014-July/021170.html
[7] https://mm.icann.org/pipermail/tz/2014-July/021248.html
[8] https://mm.icann.org/pipermail/tz/2014-August/021288.html
[9] https://mm.icann.org/pipermail/tz/2021-September/030764.html
[10] https://mm.icann.org/pipermail/tz/2021-September/030742.html

On Wed, Sep 29, 2021 at 8:22 AM Philip Paeps via tz <tz at iana.org> wrote:

> On 2021-09-29 19:20:36 (+0800), Tony Finch via tz wrote:
> > I have identified two policy changes that caused this argument.
> >
> > [...]
> >
> > I think the way to fix this is to revert both policy changes, and
> > revert
> > all the timezone merges.
>
> I agree with this.
>
> Moreover, I wonder if we should not also consider merging the contents
> of backzone back into the main data files.  The backzone file was
> introduced in 2014 as a home for out-of-scope and/or poorly-sourced
> data.
>
> Instead of providing build options to increase the size of the tzdata
> distribution, I believe we should go the other way.  Contemporary
> systems are by default "large".  Developers working on smaller embedded
> devices are accustomed to making changes to reduce the footprint of the
> data/code they consume.
>
> Note that I am not suggesting that we step away from our long-standing
> policy that timestamps before 1970 are out of scope.  My suggestion is
> that we gain nothing from putting out-of-scope data into a separate
> file.  Our documentation of the policy suffices.
>
> Philip
>
> --
> Philip Paeps
> Senior Reality Engineer
> Alternative Enterprises
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210929/ffdc9af1/attachment-0001.html>