Re: timestamptz parsing bug?
От | Dean Rasheed |
---|---|
Тема | Re: timestamptz parsing bug? |
Дата | |
Msg-id | CAEZATCX893NNUzhtBz7-+SA3mLLNrbV5M4s1twygV86Zu6nX5g@mail.gmail.com обсуждение исходный текст |
Ответ на | timestamptz parsing bug? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: timestamptz parsing bug?
Re: timestamptz parsing bug? |
Список | pgsql-hackers |
On 29 August 2011 15:40, Andrew Dunstan <andrew@dunslane.net> wrote: > > Why do we parse this as a correct timestamptz literal: > > 2011-08-29T09:11:14.123 CDT > > but not this: > > 2011-08-29T09:11:14.123 America/Chicago > > Replace the ISO-8601 style T between the date and time parts of the latter > with a space and the parser is happy again. > > > cheers > > andrew > Funny, I've just recently been looking at this code. I think that the issue is in the DTK_TIME handling code in DecodeDateTime(). For this input string the "T" is recognised as the start of an ISO time, and the ptype variable is set to DTK_TIME. The next field is a DTK_TIME, however, when it is handled it doesn't reset the ptype variable. When it gets to the timezone "America/Chicago" at the end, this is handled in the DTK_DATE case, because of the "/". But because ptype is still set, it is expecting this to be an ISO time, so it errors out. The attached patch seems to fix it. Could probably use a new regression test though. Regards, Dean
Вложения
В списке pgsql-hackers по дате отправления: