From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Inconsistent behavior with TIMESTAMP WITHOUT and epoch |
Date: | 2005-01-27 19:17:41 |
Message-ID: | 200501271117.41205.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom,
> How so? If you think that the timestamp-without-zone is relative to GMT
> rather than your local zone, you say something like
> extract(epoch from (timestampvar AT TIME ZONE 'GMT'))
Ah, that didn't seem to work before. I must have done the parens wrong.
> Quite honestly, you should be using timestamp WITH time zone for such an
> application anyway. The timestamp without zone datatype is very
> strongly biased towards the assumption that the value is in your local
> timezone, and if you've actually got multiple possible settings of
> TimeZone then it's simply a great way to shoot yourself in the foot.
Well, I was thinking about this on the way to my office this AM, and realized
that there's a fundamental gulf between timestamp-as-real-moment-in-time (the
SQL timestamp and postgres timestamp) and timestamp-as-mark-on-the-calendar
(what I'm dealing with), and that my trouble stems from trying to coerce the
first into the second.
Maybe it's time to hack a datatype ...
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-01-27 19:22:36 | Re: [GENERAL] My postmaster just crashed ! |
Previous Message | Tamas Vincze | 2005-01-27 19:08:36 | Re: 8.0.0 make check fails on Solaris 9 (sparc) |