Re: timestamptz parsing bug?

On 29 August 2011 20:43, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 08/29/2011 03:35 PM, David E. Wheeler wrote:
>>
>> On Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
>>
>>>> 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.
>>>
>>> Do we actually *want* to support this?  The "T" is supposed to mean that
>>> the string is strictly ISO-conformant, no?
>>
>> I didn't realize that appending a time zone was not conformant, but
>> apparently it's not.
>>
>>   http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>>
>> Only appending a "Z" or an offset seems to be legal. Interesting.
>>
>>
>
> In that case we shouldn't be accepting an abbreviation either.
>

The remit of the function is to support inputs in "almost any
reasonable format", not just ISO format. I'd say that supporting both
extensions of the ISO format is reasonable. Supporting one and not the
other is inconsistent, and removing support for one will likely break
someone's code.

Regards,
Dean