[tz] Undoing the effect of the new alike-since-1970 patch
paul at ganssle.io
Wed Jun 9 20:33:20 UTC 2021
I have to say I feel like the idea of a `make` flag for this purpose
seems like compromise for the sake of compromise. Isn't reducing the
maintenance burden the primary point of the zone merging and the move of
historical data into backzone? By adding a flag that generates the old
and new versions, you still have to maintain the historical data (in
backzone), and /also/ you need to maintain a program that converts the
new version into the old version.
Unlike `vanguard` / `rearguard`, where my understanding was that these
were supposed to be make targets where you use "rearguard" to buy
yourself time to support deprecated features (or load bearing bugs...)
and you use "vanguard" to opt in to stuff that will soon be the default,
this proposal seems to be /indefinitely/ introducing a schism.
The only reason I can see for doing it this way is if the concern were
about the sizes of tzdata binaries, and for people who need extra-slim
distributions they could merge a bunch of zones, but honestly for those
rare use cases it seems like it would be easier to undo the patch in its
entirety and add a utility that detects when a set of zones is identical
after a specified date (doesn't have to be 1970!) and merge all the rest
into links, for people making custom small distributions of this nature.
On 6/9/21 4:12 PM, Paul Eggert via tz wrote:
> On 6/9/21 2:29 AM, Stephen Colebourne via tz wrote:
>> I'm not worried about the comments if that is what you are thinking
>> of. I'm more concerned about exactly what the output you are proposing
>> will contain - it is not clear to me.
> Yes, I was definitely thinking of the comments. Also, the ordering of
> Zones (which is irrelevant). Stuff like that. The idea is that the
> generated TZif files should be identical to what they would have been
> without the alike-since-1970 patch. I would expect similar results in
> downstream systems that don't use TZif.
>> I've yet to see a willingness to engage on
>> backwards compatibility - to stop fiddling with the data.
> How about this: we could say that we won't do any sort of merging like
> this in the future. In other words, this is the last time we'll be
> merging legacy zones because they differ only before 1970. Would a
> statement like that help? We could put such a statement into the NEWS
> file, say.
>> your patch (and probably previous ones) are
>> making a political statement of the kind you say you don't want.
> Sure, but no matter what we do we'll be making a political statement.
> The statement I'd like to see is "let's avoid political data when we
> can". Admittedly not everyone agrees (which is also politics :-).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz