Re: Anybody care about having the verbose form of the tzdata files?

On Wed, Nov 22, 2017 at 9:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Tue, Nov 21, 2017 at 6:28 PM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>> On 20 Nov 2017, at 21:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Anybody here actually care about reading the zone data files?
>> Perhaps I do. If this set of files gets removed and replaced by the zi
>> file, is it possible to still know easily which files are being
>> removed during a minor upgrade? When doing minor upgrades of a MSI
>> installer (Windows, yeah!), I need to keep track of files that get
>> deleted or a minor upgrade would simply fail. The tweak that I have is
>> to list them and recreate them as empty. The thing is ugly as hell,
>> but I need to be able to track which files are being removed easily.
>> And as far as I am checking, for example taking the rather recent
>> example of Riyadh87 in commit e04641f4, src/timezone/data allows to
>> keep easily track of files removed. If this gets removed, I am pretty
>> convinced that this tracking gets more complicated.
>
> I'm a bit confused. The files under src/timezone/data/ don't correspond
> to individual installed zone data files; most of them describe a lot of
> zones. (Riyadh87 and friends were outliers.) Seems to me that if you
> care about the installed file list, much the easiest way is to run
> "make install" and then look to see what's under share/timezones/.
> That wouldn't change if we use the abbreviated form of the zic input
> data.

Yeah. That's basically what I do when I have a doubt, seeing an
automated minor upgrade failing or when getting a complain. But the
process is an hassle, and I can get things basically fine if I have an
easy reference of things removed.

> Now, personally, I've long diff'd the old and new timezone/data/ files
> in the process of writing the commit message for a tzdata update.
> I'd have to change that process --- but it was always a pretty tedious and
> obsessive-compulsive way to do it anyway, because most of the diffs are
> comments. I'd probably just start relying more fully on the IANA
> announcement emails, like this one:
>
> http://mm.icann.org/pipermail/tz-announce/2017-October/000047.html
>
> As far as I've seen, they are reliably good about summarizing everything
> you need to know about an update. They definitely always mention
> additions and removals of zones.

If you add a reference to those upstream announces in your commit
message, that would be fine as well for me. I don't tend to follow
those folks closely (I really should I guess).
--
Michael