Re: Timezone code, one more try

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Timezone code, one more try
Date: 2004-05-18 13:57:19
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34BA42@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

It seems this patch conflicts with Toms fix for Turkish locale. I had
avoided going to a later snapshot to avoid the fallout from the
relocateable install work Bruce did.

I will pull a newer snapshot and update this patch so it applies to a
more recent version. Should be done in a day or two max.

Sorry about not checking this before I sent it.

//Magnus

> -----Original Message-----
> From: Magnus Hagander
> Sent: Monday, May 17, 2004 10:57 PM
> To: pgsql-patches(at)postgresql(dot)org
> Subject: [PATCHES] Timezone code, one more try
>
> Ok, here is another attempt at the timezone code. (let's
> hope it's not too big to get through the patches list this
> time) Changes from last
> time:
>
> * Now used on all platforms, not just win32 (per request)
> * Removes the part of the timezone library we don't use...
> * Removes support for the system tz library, *requires* the
> new builtin one (per request)
> * As a bonus of this, removes a bunch of workarounds around
> platform specific issues
> * Attempts to pick up the OS timezone upon startup (will work
> sometimes, fail sometimes, because there really is no API to
> pick up the name of the current timezone..). Yes, this is
> certainly somewhat hackish due to this..
> * Cleans out the timezone librarys use of K&R function
> headers, changing them to ANSI
> * As a bonus, "show timezone" will now work on an
> installation that does not use the TZ env variable and does
> not have timezone specified in postgresql.conf. Previously,
> it just returned "unknown".
>
>
> For the time being, the general APIs to the timezone
> functions have not been changed. We might want to do that
> eventually, but I figured getting it to work with the current
> APIs is a good point to start.
> The only exception to this is that pg_tzset() (replacement
> for tzset) now returns a boolean value indicating if it has
> successfully changed the timezone. That got rid of a lot of
> workaround codes around the lack of failure indication.
>
>
> The patch is very large, but the bulk of it is due to:
> * The changing of the headers K&R -> ANSI
> * The replacement of all "struct tm" to "struct pg_tm" (and
> the same for the tz functions, but those are not as many)
> * The replacement of all "include <time.h>" with #include "pg_time.h"
>
> In doing this, I have also removed platform-specific
> regression test outputs. Since they all use the lib now, it
> should be fine.
>
> Attached files are:
> timezone2.patch.gz - well, the patch.
> pg_time.h - goes in src/include
> strftime.c - goes in src/timezone
>
> The following files should be removed:
> src/timezone/difftime.c
> src/timezone/asctime.c
> src/test/regress/expected/abstime-solaris-1947.out
> src/test/regress/expected/horology-no-DST-before-1970.out
> src/test/regress/expected/horology-solaris-1947.out
> src/test/regress/expected/tinterval-solaris-1947.out
>
>
> I have tested the patch, and it passes regression tests +
> some other manual tests on Win32, Linux (Slackware 9) and
> FreeBSD (5.2), all on
> i386 hardware. I'm sure there will be *some* issues on others...
>
>
> Comments?
>
>
> //Magnus
> <<timezone2.patch.gz>>
>
>

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-05-18 16:34:17 Re: new aggregate functions v1
Previous Message Andrew Hammond 2004-05-18 13:39:21 Re: pg_ctl patch to integrate apache's rotatelogs