Skip site navigation (1) Skip section navigation (2)

Re: timestamptz parsing bug?

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: timestamptz parsing bug?
Date: 2011-08-29 20:31:00
Message-ID: CAEZATCUcrfpRq_hBwxgteDmjWkP_29QwjOB572t-CTXfgJtYVQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Ants AasmaDate: 2011-08-29 21:07:18
Subject: spinlocks on HP-UX
Previous:From: Tom LaneDate: 2011-08-29 20:29:39
Subject: Re: timestamptz parsing bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group