Re: PGparam timestamp question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGparam timestamp question
Date
Msg-id 13416.1197224810@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGparam timestamp question  (Andrew Chernow <ac@esilo.com>)
Responses Re: PGparam timestamp question
List pgsql-hackers
Andrew Chernow <ac@esilo.com> writes:
> Okay, thanks.  So using WITHOUT TIME ZONE basically means, store the provided
> value as UTC.  Meaning, 8AM EST NOW() is stored/treated as 8AM UTC.

No, I think you are more confused now than you were before.

For both types, the underlying stored value is just a number-of-seconds
offset from 2000-01-01 00:00:00.  The question is what's the reference
time really.  For WITHOUT TIME ZONE, what you see is what you get: it's
just a date and time, and nobody is actually promising anything about
timezone considerations.  For WITH TIME ZONE, the convention is that the
reference time is 2000-01-01 00:00:00 UTC, and therefore it is accurate
to say that the *stored value* is always expressed in UTC.

What confuses people is that for display purposes, a TIMESTAMP WITH TIME
ZONE value is rotated to your local timezone (as set by the timezone
variable) and printed with your local zone offset.  But that's not
what's really stored.

Now, about AT TIME ZONE: that's a trickier operation than it looks.
When you start with a timestamp WITH time zone, the meaning is
"here's a UTC time, give me the equivalent local time in this time
zone".  What comes out is a timestamp WITHOUT time zone, which means
it'll just be printed as-is.
When you start with a timestamp WITHOUT time zone, the meaning is
"here is a local time in this time zone, give me the equivalent
UTC time".  What comes out is a timestamp WITH time zone, which as
we already saw is implicitly UTC inside the system, which is correct.
But you have to remember that that value will be rotated back to
your local zone for display.  I think that extra conversion is what
was confusing you to start with.

Another point to keep in mind is that if the system is forced to
assume something about the timezone of a WITHOUT TIME ZONE value,
it will assume your local time zone setting.  In particular this
happens during forced coercions between WITH and WITHOUT TIME ZONE.
So for example, in

regression=# select now(), now()::timestamp without time zone;             now              |            now

 
-------------------------------+----------------------------2007-12-09 13:21:50.619644-05 | 2007-12-09 13:21:50.619644
(1 row)

the two values are in fact different numbers-of-seconds internally.
They print the same, but that's because in the first case the
timestamp-with-time-zone output routine rotated from UTC to my
local zone (EST) during printout.  In the second case the same
5-hour offset was applied by the cast to without-time-zone, and
then the timestamp-without-time-zone output routine just printed
what it had without any magic.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: PGparam timestamp question
Next
From: Tom Lane
Date:
Subject: Re: whats the deal with -u ?