Re: Patch for PKST timezone

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Aftab Hussain <aftab(dot)se(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch for PKST timezone
Date: 2010-05-16 13:49:49
Message-ID: AANLkTil295rrv861mjtHTP5qRvsWL9ki5fjeAxh1cL_S@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 12, 2010 at 12:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joachim Wieland <joe(at)mcknight(dot)de> writes:
>> Good we have found that inconsistency now, so let's add PKST.
>
> OK, done.  BTW, I notice that PKT was labeled "(not in zic)", which
> is not the case, per this discussion.  I seem to recall having noticed
> some others that seemed to be mislabeled the same way.  What process did
> you use to compare this list to the zic files, and do we need to revisit
> it?

I have used a modified version of zic.c that outputs the data while
generating the binary timezone files. Generating the timezone offset
files from that then included some scripts and some manual work. It
seems that we should have an automated process for that, at least for
checking against our current set. I'll see if I can come up with that.
PKST for example was valid only for a single year in the past but in
the newer timezone data it is now valid forever. Ideally we can run a
script that tells us about such changes whenever we bring in new
timezone data.

Joachim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-05-16 13:54:01 Re: pg_upgrade and extra_float_digits
Previous Message Heikki Linnakangas 2010-05-16 06:55:03 Re: Performance problem in textanycat/anytextcat