Re: timestamp with/without time zone

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

> Thomas, can we change the description to just 'timestamp'?

Sure, we can do anything we want. I don't agree with all of the points
raised, and in particular disagree with the characterization of our
current "timestamp" type as having no concept of time zones, although it
is true that it has no concept of "sticky time zones" which travel with
the data value.

The description in pg_dump was chosen to assist with a transition in the
next version of PostgreSQL to having available a true "no time zone"
timestamp, leaving the current implementation as the "time zone aware"
type. I'm concerned about changing the current choice in the absence of
thought about this issue.

istm that if we dump timestamps which have time zone fields (which at
the moment all do), trying to read them back in as plain-vanilla SQL92
"timestamp" might result in an error condition, leading to dump/restore
problems. Or maybe it would be appropriate for a "time zone free" type
to just ignore time zone info in input? If so, upgrading wouldn't be as
big an issue, and just the upgraded schema would need to be
considered...

On a related note, I've been thinking about removing the following
features from our current "timestamp":

o timestamp 'invalid' - an interesting concept which might actually be
useful for the original abstime type since it has such a limited range,
but not generally useful for timestamp. I'd suggesting leaving it in for
abstime, at least for now.

o timestamp 'current' - another interesting concept not likely used by
anyone, and causing conniptions for our optimizer (one cannot cache
results for datasets containing this value).

Comments?

- Thomas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2001-06-22 15:21:42 Re: Re: Universal admin frontend
Previous Message Tom Lane 2001-06-22 15:17:18 Re: 7.2 release and index_formtuple