Re: timestamptz parsing bug?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: timestamptz parsing bug?
Date: 2012-08-15 21:29:26
Message-ID: 20120815212926.GP25473@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)dunslane(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-08-15 21:45:42 Re: [BUGS] BUG #6184: Inconsistencies in log messages
Previous Message Marko Kreen 2012-08-15 21:13:54 Re: sha1, sha2 functions into core?