Message-ID: <501BEF7C.1030403@dhs-club.com>
Date: Fri, 03 Aug 2012 11:34:20 -0400
From: Bill MacArthur <webmaster@dhs-club.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: pgsql-admin@postgresql.org
Subject: Re: Messed up time zones
References: <501B8C6F.6040100@shopzeus.com> <501BAA84.9010306@shopzeus.com>
	<501BAE33.4090102@shopzeus.com> <16399.1344003584@sss.pgh.pa.us>
	<501BED07.5070603@shopzeus.com>
In-Reply-To: <501BED07.5070603@shopzeus.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/3/2012 11:23 AM, Laszlo Nagy wrote:
>> I suspect that you have not correctly internalized what timestamptz
>> values actually are.  Internally they are just time values specified in
>> UTC (or UT1 if you want to be picky).  On input, the value is rotated
>> from whatever zone is specified in the string (or implicitly specified
>> by "timezone") to UTC.  On output, the value is rotated from UTC to
>> whatever the current "timezone" setting is.
> Oh I see. So actually they don't store the zone? I have seen that timestamptz and timestamp both occupy 8 bytes, but I didn't understand completely.
>
> It also means that if I want to store the actual time zone (in what the value was originally recorded), then I have to store the zone in a separate field. Later I can convert back to the original time zone, but only with an external program.
>
> Fine with me. I'm happy with this, just I did not understand how it works.

You could store the zone in a separate field and then create a VIEW on the table that used a function to take both values and return the timestamptz just as it was inserted.