Thread: Timestamp with timezone question.
AFAIK, the input for a timestamptz is converted and stored as UTC. And outputing a timezonetz value converts the internally stored UTC value to the current locale's timezone. So there is not a way to actually store the original TZ itself, whereas the timetz type clearly does that. Consider a schema designed to store internet mail. Since pgsql always converts a timestamptz to UTC, we have lost the information of the Sender's local timezone. Should i go with a separete date and timetz ? -- -Achilleus
On 2005-02-21, Achilleus Mantzios <achill@matrix.gatewaynet.com> wrote: > Consider a schema designed to store internet mail. > > Since pgsql always converts a timestamptz to UTC, we have lost > the information of the Sender's local timezone. > > Should i go with a separete date and timetz ? No. Consider instead storing a timestamptz with the actual time of the mail, and a separate field with an interval representing the zone offset. Then you can use AT TIME ZONE to recover the sender's local time. e.g. (this table has columns serial, timestamptz, interval) insert into dtz values (DEFAULT, '2005-03-21 07:05:00 -0800', '2005-03-21 07:05:00 -0800'::timestamp - '2005-03-21 07:05:00-0800'::timestamptz at time zone 'UTC' ); (the timestamp - timestamptz thing is just a reasonably reliable way of getting the timezone offset without complicated parsing.) select * from dtz;id | t | z ----+------------------------+----------- 1 | 2005-03-21 15:05:00+00 | -08:00:00 (1 row) select *, t at time zone z as ot from dtz;id | t | z | ot ----+------------------------+-----------+--------------------- 1 | 2005-03-21 15:05:00+00 | -08:00:00 | 2005-03-21 07:05:00 (1 row) -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
O Andrew - Supernews έγραψε στις Feb 21, 2005 : > On 2005-02-21, Achilleus Mantzios <achill@matrix.gatewaynet.com> wrote: > > Consider a schema designed to store internet mail. > > > > Since pgsql always converts a timestamptz to UTC, we have lost > > the information of the Sender's local timezone. > > > > Should i go with a separete date and timetz ? > > No. Consider instead storing a timestamptz with the actual time of the > mail, and a separate field with an interval representing the zone offset. > Then you can use AT TIME ZONE to recover the sender's local time. > > e.g. (this table has columns serial, timestamptz, interval) > > insert into dtz values (DEFAULT, > '2005-03-21 07:05:00 -0800', > '2005-03-21 07:05:00 -0800'::timestamp > - '2005-03-21 07:05:00 -0800'::timestamptz at time zone 'UTC' > ); > > (the timestamp - timestamptz thing is just a reasonably reliable way of > getting the timezone offset without complicated parsing.) > > select * from dtz; > id | t | z > ----+------------------------+----------- > 1 | 2005-03-21 15:05:00+00 | -08:00:00 > (1 row) > > select *, t at time zone z as ot from dtz; > id | t | z | ot > ----+------------------------+-----------+--------------------- > 1 | 2005-03-21 15:05:00+00 | -08:00:00 | 2005-03-21 07:05:00 > (1 row) Cool thanx. I ended up displaying the actual date header field of the SMTP message (just like the yahoo guys do). > > -- -Achilleus
On Mon, Feb 21, 2005 at 16:16:04 +0200, Achilleus Mantzios <achill@matrix.gatewaynet.com> wrote: > > Since pgsql always converts a timestamptz to UTC, we have lost > the information of the Sender's local timezone. > > Should i go with a separete date and timetz ? Someone else gave you a recommended solution. However there was a discussion on the order of 6 months ago about changing the timestamptz type to keep this information. Nothing will be changing in the near future, but you may (or may not) find the discussion useful.
O Bruno Wolff III έγραψε στις Feb 22, 2005 : > On Mon, Feb 21, 2005 at 16:16:04 +0200, > Achilleus Mantzios <achill@matrix.gatewaynet.com> wrote: > > > > Since pgsql always converts a timestamptz to UTC, we have lost > > the information of the Sender's local timezone. > > > > Should i go with a separete date and timetz ? > > Someone else gave you a recommended solution. > > However there was a discussion on the order of 6 months ago about changing > the timestamptz type to keep this information. Nothing will be changing > in the near future, but you may (or may not) find the discussion useful. Thanx, i'll check it out sometime. Apart from that, having a new (version of a) type (timestamptz) just to provide a convinience function isnt too useful. > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- -Achilleus