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 |
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 |