Re: Proposal for updating src/timezone

John Cochran <j69cochran@gmail.com> writes:
> As it is, I've finished checking the differences between the postgres and
> IANA code for zic.c after editing both to eliminate non-functional style
> differences such as indentation, function prototypes, comparing strchr
> results against NULL or 0, etc. It looks like the only differences from the
> stock code is support for the -P option implemented by Tom Lane and the
> substitution of the postgres code for getopt instead of the unix default as
> well as a few minor changes in some defaults and minor modifications to
> deal with Windows. Overall, rather small and trivial.

> Additionally, I discovered a little piece of low hanging fruit. The
> Makefile for the timezone code links together zic.o ialloc.o scheck.o and
> localtime.o in order to make zic.  Additionally, zic.c has a stub
> implementation of pg_open_tzfile() in order to resolve a linkage issue with
> the localtime.o module for zic.
> Well, as it turns out, localtime.o doesn't supply ANY symbols that zic
> needs and therefore can be omitted entirely from the list of object files
> comprising zic. Which in turn means that the stub implementation of
> pg_open_tzfile can be removed from the postgres version of zic.c.  I'm not
> bothering to submit a patch involving this since that patch will be quite
> short lived given my objective to bring the code up to date with the 2014e
> version of the IANA code. But I am submitting a bug report to IANA on the
> Makefile since the unneeded linkage with localtime.o is still in the 2014e
> code on their site.

John, have you made any further progress on this since July?

The urgency of updating our timezone code has risen quite a bit for me,
because while testing an update of the data files to tzdata2014h I became
aware that the "-P" option is failing to print a noticeable number of
zone abbreviations that clearly exist in the data files.  Since the -P
hack itself is so simple, it's hard to come to any other conclusion than
that the rest of the timezone code is buggy --- presumably because it's
four years behind what IANA is targeting with the data files.

I spent a little bit of time looking at just applying the diffs between
tzcode2010c and tzcode2014h to our code, but the diffs are large enough
that that seems both tedious and quite error-prone.  I think we'd be
better advised to push forward with the idea of trying to absorb
more-or-less-unmodified versions of the timezone code files.  (I'm
particularly disillusioned with the idea that we'll keep on pgindent'ing
that code --- the effort-to-reward ratio even to keep the comments
readable just ain't very good.)
        regards, tom lane