On Thursday 21 October 2004 11:01, Dennis Bjorklund wrote:
> On Thu, 21 Oct 2004, Tom Lane wrote:
> > I'm aware that there are aspects of the spec behavior that appear to
> > require that, but is it really an improvement over the implementation
> > we have?
>
> Improvement and improvement. The actual time value is of course the same
> (the utc part of a timestamp) and the only thing extra you get is that the
> time zone is stored. The extra information you do have now, when stored in
> this way, is that you store both a utc time and a local time. Will any
> application ever need that? Who knows? I think it makes sense and is an
> easier model to think about then what pg uses today. So I would use it
> even if it means using 2 bytes more storage then what timestamptz do
>
In a fit of early morning, pre-coffee thoughts, I'm thinking this might be
just what I've been looking for. In one of my apps we take calls from around
the country for customers and store the time that call came in. Unfortunately
we need to know things like how many calls did we take in an hour across
customers, but also how many calls did we take at 6AM local time to the
customer. The way PostgreSQL works now, you have to store some extra bits
of info in another column and then reassemble it to be able to determine
those two queries, but it sounds like your timestampstdtz would allow that
information to be stored together, as it should be.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL