...
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:
...
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:Thomas, what do you think --- was this behavior deliberate or an oversight?
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);
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
