Re: [HACKERS] Copy from/to asymmetry
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Copy from/to asymmetry |
Дата | |
Msg-id | 387D59D3.FB3DCE60@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Copy from/to asymmetry (Michael Robinson <robinson@netrinsics.com>) |
Ответы |
Re: [HACKERS] Copy from/to asymmetry
|
Список | pgsql-hackers |
> I set my time zone to GMT+8 today (because the "official" timezone prescribed > by the FreeBSD timezone database for my location is "CST", which was causing > all sorts of other problems elsewhere). ... > I was able to recover in a few minutes by manually editing the script file > to replace all "GMT+8" with "+0800". ... > I assume that my backups are similarly corrupted. Sure, if you were running with a similarly unusual timezone format. > I looked through dt.c, and ParseDateTime appears to assume that timezones > are either strictly alphabetic or of the form "+0000". Right, those are the forms we have seen or heard about (the minutes field in the second form is optional). Yours is a new one for me. > EncodeDateTime, > on the other hand, blindly spits out whatever the operating system gives it > from localtime(). Yup. afaik this is the only way to get daylight savings time info since there is no api to do so otherwise. Since this is the very first report of this style of timezone, I don't feel too guilty, and it will be easy to fix (I hope anyway). > 1. x == datetime_in(datetime_out(x)) should always be true for all valid x. Impossible to do apriori, given that we rely on the system to provide timezone info for output. However, we try to fix all unusual cases, and afaik there are no reasonable formats we have rejected for support. I'm leaving town for a couple of days, but will look at it when I return. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: