...
> In the long run, seems like it would be a good idea for type TIME
> WITHOUT TIME ZONE's input converter to accept and ignore a timezone
> field, just as type TIMESTAMP WITHOUT TIME ZONE does:
...
> Thomas, what do you think --- was this behavior deliberate or an
> oversight?
The behavior was deliberate, but predates the implementation of
TIMESTAMP WITHOUT TIME ZONE. The time zone is already ignored when
converting directly from TIME WITH TIME ZONE to TIME WITHOUT TIME ZONE:
lockhart=# select cast(time with time zone '2002-11-06
22:25:57.796141-05' as time);
time
-----------------
22:25:57.796141
and one could claim that this should be allowed from string constants too:
thomas=# select cast('2002-11-06 22:25:57.796141-05' as time);
time
-----------------
22:25:57.796141
Patch included to allow this latter case...
- Thomas
Index: date.c
===================================================================
RCS file: /home/thomas/cvs/repository/pgsql-server/src/backend/utils/adt/date.c,v
retrieving revision 1.73
diff -c -r1.73 date.c
*** date.c 21 Sep 2002 19:52:41 -0000 1.73
--- date.c 7 Nov 2002 06:32:05 -0000
***************
*** 511,516 ****
--- 511,517 ----
fsec_t fsec;
struct tm tt,
*tm = &tt;
+ int tz;
int nf;
char lowstr[MAXDATELEN + 1];
char *field[MAXDATEFIELDS];
***************
*** 521,527 ****
elog(ERROR, "Bad time external representation (too long) '%s'", str);
if ((ParseDateTime(str, lowstr, field, ftype, MAXDATEFIELDS, &nf) != 0)
! || (DecodeTimeOnly(field, ftype, nf, &dtype, tm, &fsec, NULL) != 0))
elog(ERROR, "Bad time external representation '%s'", str);
tm2time(tm, fsec, &result);
--- 522,528 ----
elog(ERROR, "Bad time external representation (too long) '%s'", str);
if ((ParseDateTime(str, lowstr, field, ftype, MAXDATEFIELDS, &nf) != 0)
! || (DecodeTimeOnly(field, ftype, nf, &dtype, tm, &fsec, &tz) != 0))
elog(ERROR, "Bad time external representation '%s'", str);
tm2time(tm, fsec, &result);