Re: Proposal for updating src/timezone

On Fri, Jul 18, 2014 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> John Cochran <j69cochran(at)gmail(dot)com> writes:
> > My proposal is the have the following directory structure
>

> ...
> > 1. I would have liked to recommend 2 sub-directories underneath
>
...

>
>
I have exactly zero expectation of using their Makefile, so this is not a
> concern.
>
> > 2. Depositing the IANA code unaltered would also deposit some "junk"
> files
>
...

> We're not doing that either, IMO. Why should we invest 500K of tarball
> space on that?
>

Understandable, and both issues are in the category of "Things I didn't
like"

Did a diff between the 2010c version of localtime.c and the postgres
version and saw a lot more differences than what could have been expected
from simple reformatting and adaptation. So I installed gitk and took a
look at the change history of localtime.c....

Well, looking at the results, it pretty much put paid to the concept of
ever importing the IANA code unaltered into the postgres tree. In fact, it
looks like the original version of localtime.c was based upon one of the
2004a thru 2004c versions of the IANA code and since then has been
independently maintained.

In any case, I think my best path forward is to look at the change history
of the source files under src/timezone and determine the actual origin of
each file based upon the git history and the IANA archive. Then see what's
needed to bring the code up to date based upon the IANA code. Due to the
configure option "--with-system-tzdata", I assume that postgres needs to
remain compatible with the output from the IANA zic program. That combined
with the warning messages about some of the entries in the current timezone
data not being compatible with pre-2013 code worries me a bit since the
2010c code from IANA does not support the output from the 2014e zic.
--

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