Thread: Timestamp change - 8601 compliance

With XSDs right around the corner using ISO 8601 compliant dates, what
are the chances Postgres could fully support them?

The primary difference between that and what it does now is a T for
the date / time seperator rather than a space and the potential for a
Z for the timezone seperator.

I'm convinced this was done to piss me off and enforce conversion
routines for databases to actually accept the information passed.

Info:

1999-05-31T13:20:00.000-05:00

May 31st 1999 at 1.20pm Eastern Standard Time which is 5 hours behind
Co-Ordinated Universal Time

http://www.cs.utsa.edu/~wagner/date/8601.pdf
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime
--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

> With XSDs right around the corner using ISO 8601 compliant dates, what
> are the chances Postgres could fully support them?

Good.

> The primary difference between that and what it does now is a T for
> the date / time seperator rather than a space and the potential for a
> Z for the timezone seperator.

The currently accepted date/time format *is* ISO-compliant. However,
there is the "machine interchange" (my quotes) version which has the
embedded "T" and "Z" fields.

> I'm convinced this was done to piss me off and enforce conversion
> routines for databases to actually accept the information passed.

Of course ;)

I have patches to support a "julian day" format (with a leading "J" or
"JD"), and istm that support for the "T" and "Z" fillers would be close
to trivial. I'll try some testing...
                        - Thomas