Jürgen Appel wrote in <2116792.6t3XcvbCL1@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)