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 <and...@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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
