From: | Michael Robinson <robinson(at)netrinsics(dot)com> |
---|---|
To: | lockhart(at)alumni(dot)caltech(dot)edu, pauls(at)caemrad(dot)com(dot)au, robinson(at)netrinsics(dot)com |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] timezone problem? |
Date: | 2000-01-21 08:39:00 |
Message-ID: | 200001210839.QAA01497@netrinsics.com |
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?
Yes, and even worse, CST also is "China Standard Time" in some operating
systems. I won't go into how broken every operating system is vis-a-vis
Chinese timezones (but, believe me, it's a mess).
>From here on out, I'm strictly in "+0800".
>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 :(
I've become convinced that any project that thinks it is going to keep
comprehensive, accurate, non-conflicting, non-obsolete timezone information
in an application-specific table is woefully misguided.
>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.
Does this patch apply cleanly against 6.5.3?
-Michael Robinson
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-01-21 08:39:03 | Re: Status on 7.0 |
Previous Message | Michael Meskes | 2000-01-21 07:35:07 | Re: [HACKERS] off topic |