Thread: Feature-request: allowing the date/time type to accept ISO8601 compliant date/time combinations on input

L.S.


Problem:

The date/time type in version 7.3.1 separates the two pieces of information in
a combined date/time field with the character <space>. IMHO this is the
preferable way for output, but it would be nice when one could use the formal
ISO 8601 specification for input as well, instead of having to use the same
<space character>.


Data:

The ISO8601 specification (ref.nr. ISO/TC 154 N 362 dated 2000-12-19) in
paragraph 5.1.2 (page 10) describes the use of designators. It states that
the character <T> is used as time designator for (amongs other things):

"the start of the representation of the time of day in combined date and time
expressions"

Paragraph 5.4.1 (page 18) mentions the following note:

"By mutual agreement of the partners in information interchange, the character
[T] may be omitted in applications where there is no risk of confusing a
combined date and time of the day representation with others defined in this
International Standard."



Request:

Please allow input of the form

    "1997-12-17T07:37:16-08"

as well as

    "1997-12-17 07:37:16-08"






--
Regards,




Frank van Vugt


Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> Please allow input of the form
>     "1997-12-17T07:37:16-08"

Seems to be there already since 7.2.

regression=# select '2003-01-09 09:23:51.308301-05'::timestamptz;
          timestamptz
-------------------------------
 2003-01-09 09:23:51.308301-05
(1 row)

regression=# select '2003-01-09T09:23:51.308301-05'::timestamptz;
          timestamptz
-------------------------------
 2003-01-09 09:23:51.308301-05
(1 row)

regression=# select version();
                            version
---------------------------------------------------------------
 PostgreSQL 7.2.3 on hppa-hp-hpux10.20, compiled by GCC 2.95.3
(1 row)


            regards, tom lane

> > Please allow input of the form
> >     "1997-12-17T07:37:16-08"
>
> Seems to be there already since 7.2.


You are *absolutely* correct.....!

I should have known better and doubt PostgreSQL only as a 'last resort' -> the
problem was caused by a lib sending PostgreSQL something else then it was
telling me, the pgsql log showed the truth ;\

Sorry 'bout that...





Frank.