Re: timestamp with/without time zone

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Subject: Re: timestamp with/without time zone
Date: 2001-06-19 01:25:08
Message-ID: 9452.992913908@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Very few people know the standards stuff so it seems we should just call
> it timestamp and do the best we can. Basically by mentioning "with
> timezone" we are making the standards people happy but confusing our
> users.

I don't believe we're making any standards-lovers happy either, because
the datatype in question *is* *not* SQL9x's TIMESTAMP WITH TIME ZONE.
Given that no one actually wants to change its behavior to conform to
either of the standard's datatypes, ISTM that calling it something
different from either of those two is the appropriate path.

At some point (if someone is foolish enough to want to implement the
spec's semantics) we might have three distinct datatypes called
timestamp, timestamp with time zone, and timestamp without time zone,
with the first of these (the existing type) being the recommended
choice. What we have at the moment is that lacking implementations
for the last two, we map them into the first one. That doesn't seem
unreasonable to me. But to have a clean upgrade path from one to three
types, we need to be sure we call the existing type what it is, and not
mislabel it as one of the spec-compliant types.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-06-19 01:28:04 Re: timestamp with/without time zone
Previous Message Bruce Momjian 2001-06-19 01:11:06 Re: Re: Various silliness in heap_getnext and related routines