Re: Proposal for updating src/timezone - Mailing list pgsql-hackers

From John Cochran
Subject Re: Proposal for updating src/timezone
Date
Msg-id CAGQU3n6Mc_8H2K6sS7=oYeOpJU_TG9Qzrpg1NVY_vgsSkSmKbQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for updating src/timezone  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for updating src/timezone  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jul 18, 2014 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Cochran <j69cochran@gmail.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

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Making joins involving ctid work for the benefit of UPSERT
Next
From: Jeff Janes
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]