Re: Proposal for updating src/timezone

On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck <mbanck(at)gmx(dot)net> wrote:
SNIP
>
> Maybe if you pgindent the IANA code as well, you can more easily diff
> the actual changes between the two, did you try that?
>
>
> Michael
>

Unfortunately, pgindent doesn't work well with the IANA code as evident by
some previous checkins.

To quote a checkin done 2004-05-21 16:59:10 by Tom Lane
pgindent did a pretty awful job on the timezone code, particularly with
respect to doubly-starred comment blocks. Do some manual cleanup.

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.

--

There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies and the other way is to
make it so complicated that there are no obvious deficiencies. — C.A.R.
Hoare