Re: [HACKERS] timezone problem?

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

In response to

Responses

Browse pgsql-hackers by date

  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