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