Re: [HACKERS] timezone problem?

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Paul Schulz <pauls(at)caemrad(dot)com(dot)au>, Michael Robinson <robinson(at)netrinsics(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] timezone problem?
Date: 2000-01-21 07:16:55
Message-ID: 388807E7.12B3BEB3@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> If a datetime variable is read out, and then inserted back in again
> (verbatim) I get a change in the time value. I suspect that it because
> out lime zona Australia/Adelaide is CST, which I belive is also an
> American timezone. Trimming the timezone info (CST) off, fixes this
> problem. Can anyone shed any light?

Yup. Fully 1/4 of our timezone lookup table is consumed by Australian
time zones (y'all have multiple names for *everything*!). There are
some name conflicts, of course :(

> How does one get the +1030 timezone format?

Use ACSST or CADT or SADT (at least that is what is defined in the
Postgres lookup table for *exactly* the same time offset).

Or...

Apply the enclosed patch, then compile the backend with:

-DUSE_AUSTRALIAN_RULES=1

(Or move to another country. Recompiling the backend is probably
easier... ;)

This is covered in the docs in the appendix on "Date/Time Support",
but CST was not included and it looks to me that EAST had sign
trouble. Both are fixed in the enclosed patch.

btw, the patch also tries to fix the "GMT+hhmm" timezone format
reported recently as being available on FreeBSD; perhaps someone could
test that at the same time.

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

Attachment Content-Type Size
dt.c.patch text/plain 1.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2000-01-21 07:35:07 Re: [HACKERS] off topic
Previous Message Hiroshi Inoue 2000-01-21 07:03:35 RE: [HACKERS] vacuum timings