> > Hmm, I'm confused. The timestamp type doesn't actually have a time zone
> > stored, does it? Why did you want it to be dumped as "timestamp with time
> > zone" then?
Because it has "time zone aware behavior". And the input carries time
zone information, either implicitly or explicitly. And the output
carries time zone information. But...
> Andreas pointed that out awhile ago. I'm inclined to agree: equating
> timestamp to timestamp with time zone is dead wrong, and we should
> revert that pg_dump change.
This issue is not as black and white as you seem to think. As you
probably know, the SQL9x definitions for date/time types are
fundamentally flawed, with no possibility for awareness of DST, local
time, etc etc. Cf Date and Darwen for a discussion of other aspects of
the problems. I don't really care whether what we currently have is
"timestamp" or "timestamp with time zone", but if, for example, I/we
implement an SQL9x-conforming "timestamp with time zone" it will not get
used. So where do we want our current data type to fit in, and how do we
want to "fill in the edges" of our feature set? An enlightened
discussion would be helpful here, though since we are not in a position
to discuss fundamental changes at the moment perhaps limiting it to
"which side of the fence?" for the existing timestamp implementation
would be sufficient.
- Thomas
