Paul Eggert <eggert@cs.ucla.edu> writes:
Tom Lane wrote:
FWIW, Postgres has already switched over from shipping the raw tzdb text files in our tarball to shipping tzdata.zi, precisely because it's a lot smaller and you get the same output after running it through zic.
Thanks for letting me know. I have a version-related question about that.
zishrink.awk currently avoids some optimizations (and thus generates a longer file than it could) for compatibility with zic 2017b and earlier. I was thinking of enabling those optimizations in a few months, on the theory that tzdata.zi is a relatively new feature and anybody who's using it is also using a newer zic.
So my question is: does "running it through zic" mean running tzdata.zi through the system zic (which is not always present, and which may predate 2017b), or does it mean running tzdata.zi through your own copy of zic?
We run it through our own copy of zic --- generally, that subsystem is meant to support platforms that don't have tzdb at all, so we couldn't really expect zic to be available either. (On well-maintained platforms, people typically configure Postgres to use the platform's copy of tzdb not its own, whereupon updates are not our problem.) We are somewhat more slothful about updating our copy of the tz code than tz data, but all our currently-maintained release branches are currently synced to tzcode 2018e, so it'd be no problem for us if you do something that requires a current zic. In general, anytime you guys do something to the data that requires tzcode >= NN, we have to be sure we're up to NN because of the possibility that platform copies of tzdb will get the update almost immediately, whether or not we update our copy of the data. So that tends to be a stronger forcing function than zic proper anyway. Thanks for asking! regards, tom lane