From: | Jim Nasby <jimn(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timetz storage vs timestamptz |
Date: | 2006-10-06 03:27:11 |
Message-ID: | 731838C0-A99A-4D39-A894-9DA87A081666@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 3, 2006, at 5:32 PM, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
>> Why is it timestamptz can store a date and time to 1 microsecond in 8
>> bytes but a timetz needs 12 to store just the time to 1 microsecond?
>
> It's tracking the timezone explicitly ... something that timestamptz
> really ought to do too.
Wow, the docs are totally unclear on that. I believe that explains
bug 2661.
Yes, it would be nice to store the timezone in timestamptz or an
equivalent, but there's also a use for the current behavior. In many
cases, you don't care what the original timezone was; you just want
to make sure that everything is getting stored in UTC (and then
converted to your local timezone on the way back out).
I'm thinking time[stamp], time[stamp]tz (which should do what timetz
does), and time[stamp]utc (doing what timestamptz does).
In the meantime I'll try and clarify the docs on this.
--
Jim Nasby jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Singer | 2006-10-06 03:37:30 | Re: 8.2beta1 failure on IRIX |
Previous Message | Jim Nasby | 2006-10-06 03:20:21 | Re: Pie-in-sky dreaming about reworking tuple layout entirely |