Re: [HACKERS] timezone problem?
| От | Michael Robinson | 
|---|---|
| Тема | Re: [HACKERS] timezone problem? | 
| Дата | |
| Msg-id | 200001210839.QAA01497@netrinsics.com обсуждение исходный текст | 
| Ответ на | Re: [HACKERS] timezone problem? (Thomas Lockhart <lockhart@alumni.caltech.edu>) | 
| Список | 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
В списке pgsql-hackers по дате отправления: