Re: timestamp with/without time zone

> >> Let's switch 'timestamp with time zone' back to 'timestamp'. This just
> >> makes no sense.

> > I wasn't following that discussion. Why would we have a timestamp with
> > no timezone anyway?

To be "compatible" with the SQL9x brain damage. Support of standards in
this area is a big step backwards in functionality.

> The discussion isn't about what the datatype *does*, but only about what
> it's *called*.

I'd be supportive (and willing to consider doing the work ;) for one of
several options:

1) implement "timestamp without timezone", moving the current
implementation to be "timestamp with time zone".

2) implement true SQL9x "timestamp with time zone", and move the current
implementation back to "datetime". I'd consider this a real pita since
the only reason I moved it from that originally is that *no one*, over a
period of years, was willing to take responsibility for a compliant
"timestamp" implementation. We all agreed to the original change, and I
raised this as an issue back then. Oh, and SQL9x "timestamp with
timezone" is truly brain damaged, and you should be sure that this is
what you would really want. Really really want.

3) continue the status quo, with modest relabeling of the current
capabilities.

> We currently transform requests for "timestamp", "timestamp with
> timezone", and "timestamp without timezone" into the same "timestamp"
> datatype. This is fine by me. However, I think that that datatype
> should display as just "timestamp" in psql displays and pg_dump output.
> The datatype does not act exactly the same as SQL92's "timestamp with
> timezone", so it seems to me that displaying it that way just confuses
> people. However, Thomas disagreed when last heard from...

Hmm. Any solution will have some confusion, so it really is not clear
which labeling path is preferable. Maybe even to those who think it is
clear ;)

SQL9x "timestamp" has no notion of time zones. PostgreSQL "timestamp"
does. This is likely the reason for the current labeling scheme (at
least in pgdump). This also lays the groundwork for more seamless
upgrade paths later when a "time zone free" timestamp type might be
available.

- Thomas