Re: Proposal for updating src/timezone

Agreed. Right now, I'm seeing about updating zic.c to match the IANA code
combined with the modifications that postgres did to it. So far, it doesn't
look like many functional changes have been done, but due to the use of
pgindent, there's a LOT of cosmetic changes that add one heck of a lot of
noise in determining the actual differences. After I get the code closely
matching the IANA code, I'll submit a patch (unfortunately it will pretty
much be an entire replacement of zic.c due to the massive changes IANA did
between 2010c and 2014e). I will request very strongly that pgindent not be
used again on the IANA code so future maintainers can easily perform a diff
between the IANA code and the postgres code to determine the actual
differences. I'll then see about doing the same with the other source files
in timezone.

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

> John Cochran <j69cochran(at)gmail(dot)com> writes:
> > 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.
>
> That's certainly true, but I'm not sure that we should give up all that
> easily on getting closer to the IANA code again. For one thing, some of
> the thrashing had to do with the fact that we went over to 64-bit
> timestamps sooner than the IANA crew did. I'm assuming that they insist
> on 64-bit arithmetic now; we do too, so for instance some of the typedef
> hacking might no longer be necessary.
>
> AFAICT from a quick scan of the git logs, the main thing we've done to the
> API that's not in IANA is invent pg_next_dst_boundary(). Perhaps that
> could be pushed into a separate source file.
>
> Even if we only got to a point where the sources were the same except for
> a few narrow patches, it would make tracking their updates much easier.
>
> regards, tom lane
>

--

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