Re: timestamptz parsing bug? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: timestamptz parsing bug?
Date
Msg-id 20120815212926.GP25473@momjian.us
Whole thread Raw
In response to Re: timestamptz parsing bug?  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: timestamptz parsing bug?
List pgsql-hackers
I assume we want to apply this patch based on discussion that we should
allow a wider range of date/time formats.

---------------------------------------------------------------------------

On Mon, Aug 29, 2011 at 06:40:07PM +0100, Dean Rasheed wrote:
> 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

> diff --git a/src/backend/utils/adt/datetime.c b/src/backend/utils/adt/datetime.c
> new file mode 100644
> index 3d320cc..a935d98
> *** a/src/backend/utils/adt/datetime.c
> --- b/src/backend/utils/adt/datetime.c
> *************** DecodeDateTime(char **field, int *ftype,
> *** 942,947 ****
> --- 942,957 ----
>                   break;
>   
>               case DTK_TIME:
> +                 /*
> +                  * This might be an ISO time following a "t" field.
> +                  */
> +                 if (ptype != 0)
> +                 {
> +                     /* Sanity check; should not fail this test */
> +                     if (ptype != DTK_TIME)
> +                         return DTERR_BAD_FORMAT;
> +                     ptype = 0;
> +                 }
>                   dterr = DecodeTime(field[i], fmask, INTERVAL_FULL_RANGE,
>                                      &tmask, tm, fsec);
>                   if (dterr)

> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: sha1, sha2 functions into core?
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #6184: Inconsistencies in log messages