Re: Problems with Timezones in Australia - Mailing list pgsql-general

From Roderick A. Anderson
Subject Re: Problems with Timezones in Australia
Date
Msg-id 48F75519.6040302@acm.org
Whole thread Raw
In response to Re: Problems with Timezones in Australia  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Problems with Timezones in Australia  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List pgsql-general
Tom Lane wrote:
> "Roderick A. Anderson" <raanders@acm.org> writes:
>> Tom Lane wrote:
>>> No, you're behind the times: 8.2.4 and 8.1.9 are too old to know
>>> about this year's changes in southeast Australia DST laws.  Which
>>> I imagine is what's biting you.
>
>> Doesn't Pg use tzdata (at least that's what it's called on for
>> Redhat-ian distributions) for it's timezone information?
>
> Yes.  tzdata didn't know about those changes back then, either ;-)
>
> If you meant to say "why aren't we using the system's copy of
> tzdata", it's because we need to run on systems that don't have one.

No criticism intended.  Just trying to understand and find out if I
needed to make changes in my update procedures.

> If you are on a platform that uses the standard "Olsen" tz database
> and you have confidence that it will get updated regularly, you can
> configure PG to use that copy instead of its built-in copy ... but
> this isn't the default.

CentOS 5 -- three, four, or maybe more, updates this year so far.  :-)

Is there a way to determine from a binary install (Devrim GÜNDÜZ's rpms)
if it uses the system timezone data or the build-in copy?  Heck I'll
just look at the src rpm.


Thanks,
Rod
--

pgsql-general by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?
Next
From: Tomasz Myrta
Date:
Subject: Re: PQescapestringConn not found in libpq.dll