[tz] [tz-announce] 2021b release of tz code and data available

[Steffen Nurpmeso]

Jürgen Appel wrote in
 <2116792.6t3XcvbCL1 at gimli>:
 |On Saturday, 25 September 2021 02.58.09 CEST Paul Eggert via tz-announce \
 |via 
 |tz wrote:
 |
 |> The 2021b release of the tz code and data is available.

 |Thanks, this gives us some time to discuss more calmly now.

Is this still not over?
And why just immediately in advance reiterating the same wrong
arguments?

  ...
 |Either you still totally do not understand all the emails concerning this 
 |subject (which would surprise me and be very concerning for the TZ 
 |coordinator)  or you are deliberately misrepresenting what happened \
 |here over 
 |the last half year (which I personally find insulting to the community \
 |here 
 |and does not bode well for a constructive upcoming discussion):
 |
 |I  cannot find any request to reduce the number of zone-to-link-changes \
 |to any 
 |other number than zero in my records.
 |
 |Instead, there were numerous relevant issues with the proposed changes \
 |raised, 
 |among those were (I might have forgotten some):
 | * Software incompatibilities

This process goes on since 2013.  Which incompatibilities?

There are two downstream libraries which offer broken interfaces.
They are data consumers and can simply add "backzone" to the set
of zones they include.  If they do not, they are fascistic.

This holds for _all_ downstream consumers which sit on this list
and gave a s..t on backzone in the last decade anyway btw, but
nonetheless happily included all pre-1970 data.

If they do not want to include zones "which have no attached
comments", claiming these are of worse quality, which may be true,
they should either preprocess/filter those with a simple say
awk(1) snippet, or do the same but also request splitting of
backzone into "backzone" and say "unreliable".

 | * Equality  issues (not everyone seems to share your view on what is 
 |equitable)

Sheer nonsense.  And that from Denmark.

 | * Data correctness issues (after the patch users will receive knowingly \
 | wrong 
 |data for <1970 instead of best-effort data)

But only if all those packagers fail to just spend a bit of
responsibility to what they ship to their users.
Again Denmark failed to give a s..t for other areas of the world.

(..which are expected to lick the master's hands giving wheat or
covid vaccines, the same master who ravaged all thinkable
ressources, btw.  No.)

 | * Objection on the Zone-Link conversion itself and the request for a 
 |discussion on the roles of backdata and the main data base.

You mean backzone and surely not backward.
What problem do you actually have?  A zone is a link is a zone is
a link, and if not, you did something wrong.  Prove the opposite.

 | * Issues with the intransparency on whether a user is using a Link \
 | or Zone in 
 |various software packages and the consequences thereof.

Failed downstream design that does not matter in practice, and
copying other peoples failed design without adding one thought on
its own, maybe.
That is a grossly ridiculous argument.

 | * Loss of information on the quality of the pre1970 data, 
 | * The worry of forks and the fragmentation of the user base / compatibil\
 | ity 
 |with other software;
 | * issues of a change in behavior for pre-1970 data for a significant \
 | number 
 |of users also especially for the Android userbase where software updates \
 |seem 
 |(more than just) difficult.

Not that i start bitter laughing on Android updates.

That non-existing Android strategy should actually be treated as
mass-murder by the International Criminal Court, and the
responsible people be removed from the public.
The sheer amount of damages that this aggressive
you-need-to-buy-a-new-smarthone to keep up war strategy caused on
the environment is unbelievable!  Especially in those countries
that you from Denmark did not care for when their zones were
moved, shall that be true.  Pew!

 |I grant, that some or even most of these issues probably have been \
 |prevalent 
 |since much older time, but as the link-merging so far mostly affected \
 |zones 
 |without a contributing, active, numerous, interested,  enabled or active \
 |user 
 |community, the effects probably have not been noticed or raised in \
 |this list 
 |until recently. 

That is fascism really.  Shall i ever see a poor man who knows
what real hunger is, and who sheperds his old smartphone or his
old computer as the real treasure that it is, i will give him
a buffalo nickle in your name.

So enough research i let the rest.
That is me who would rejoin the data and use tooling not physical
separation to cause the IANA standardized date and time range.
Maybe i would move really dubious data to an "unreliable" file and
of course not include it.

Other than that the amount of filth in this thread is disgusting.
This project has very clear documentation, and follows
a standardized orchestration.  80-90 percent of mails in this
thread confuse personal impotence with offences of the IANA TZ
project and its maintainer.

Reality of downstream consumers is that changes to package
versioning, entire build systems, and project layout and ordering
is a very common thing in at least the free software world.
That alone is the truth.

A happy Sunday.
Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)