On Wed, Sep 16, 2009 at 2:23 AM, Kevin Grittner wrote:
> Scott Mohekey wrote:
> > I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> > TIMESTAMP at GMT. We then convert it to a users local timezone
> > within application code.
>
> TIMESTAMP WITHOUT TIME ZONE is stored "raw" and
On Sep 15, 2009, at 11:01 AM, Andrew Gierth wrote:
If you want to store both a timestamp and an associated timezone you
can do
it right now, using a composite type or two columns, with the
advantage that
you get semantics that you can rely on.
How would a composite work in practice? Can yo
Andrew Gierth wrote:
> (To me, the fact that the spec's idea of 2009-01-31 + 1 month
> corresponds to a value that current_date will never be equal to is
> a far greater show-stopper.)
You get to pick which way you want to normalize that to the calendar
-- 31 days past the start of the next mo
Tom Lane wrote:
> [ shrug... ] We *have* that property, for sane cases such as
> adding and subtracting a fixed number of days.
Adding and subtracting months is very common in business software.
I have seen application bugs related to this many times. I suspect
that such bugs would occur les
Tom Lane wrote:
For less sane cases, I would point
out to Codd that the current calendar system was not designed by
mathematicians, and trying to superimpose strict mathematical rules on
it just leads to nonsense (like the spec's requirements).
He's not listening
> "Kevin" == Kevin Grittner writes:
>> Given that the spec requires that 2009-01-31 + interval 1 month =
>> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
>> think we can safely ignore virtually everything it says about
>> date/time handling.
Kevin> Codd went on at
"Kevin Grittner" writes:
> Andrew Gierth wrote:
>> Given that the spec requires that 2009-01-31 + interval 1 month =
>> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
>> think we can safely ignore virtually everything it says about
>> date/time handling.
> Codd went on at so
On Sep 15, 2009, at 10:17 AM, Tom Lane wrote:
try=# select extract(timezone_hour from '2001-02-16 20:38:40 America/
Los_Angeles'::timestamptz);
You appear to be confusing what PG currently does with what the spec
says.
Sorry, I thought you were referring to what PostgreSQL does. Would I
be
"David E. Wheeler" writes:
> On Sep 15, 2009, at 8:50 AM, Tom Lane wrote:
>> See TIMEZONE_HOUR, TIMEZONE_MINUTE field specifications, in particular
> try=# select extract(timezone_hour from '2001-02-16 20:38:40 America/
> Los_Angeles'::timestamptz);
You appear to be confusing what PG currently
On Sep 15, 2009, at 8:50 AM, Tom Lane wrote:
See TIMEZONE_HOUR, TIMEZONE_MINUTE field specifications, in particular
b) Otherwise, let TZ be the interval value of the implicit
or explicit time zone associated with the expression>. If is TIMEZONE_HOUR, then
Andrew Gierth wrote:
>> ""Kevin" == "Kevin Grittner"
> writes:
>
> Kevin> TIMESTAMP WITH TIME ZONE is not completely ANSI-compliant,
>
> Given that the spec requires that 2009-01-31 + interval 1 month =
> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
> think we can saf
David Fetter writes:
> On Tue, Sep 15, 2009 at 11:02:52AM -0400, Tom Lane wrote:
>> EXTRACT()?
> I see that EXTRACT() can take a time zone as input, but I don't see
> anywhere that could distinguish among the following inputs, once
> stored, as they have identical representations in UTC:
See TIM
On Tue, Sep 15, 2009 at 11:02:52AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I've looked through SQL:2008 (well, through
> > 6WD2_02_Foundation_2007-12.pdf), and I didn't find anything that
> > implies that the input time zone needs to be retrievable, nor
> > anything that would specify th
> ""Kevin" == "Kevin Grittner" writes:
Kevin> TIMESTAMP WITH TIME ZONE is not completely ANSI-compliant,
Given that the spec requires that 2009-01-31 + interval 1 month = 2009-02-31
(yes, really! see general rule 4 in subsection 6.30), I think we can safely
ignore virtually everything it sa
David Fetter writes:
> I've looked through SQL:2008 (well, through 6WD2_02_Foundation_2007-12.pdf),
> and I didn't find anything that implies that the input time zone needs
> to be retrievable, nor anything that would specify the syntax for
> doing so.
EXTRACT()?
regards,
On Tue, Sep 15, 2009 at 09:23:09AM -0500, Kevin Grittner wrote:
> Scott Mohekey wrote:
> > I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> > TIMESTAMP at GMT. We then convert it to a users local timezone
> > within application code.
>
> That sounds like an accident waiting to
Scott Mohekey wrote:
> I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> TIMESTAMP at GMT. We then convert it to a users local timezone
> within application code.
That sounds like an accident waiting to happen. Sure, you can make
it work, but you're doing things the hard way,
I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as TIMESTAMP
at GMT. We then convert it to a users local timezone within application
code.
Scott Mohekey
Systems/Application Specialist – OnTrack – Telogis, Inc.
www.telogis.com www.telogis.co.nz
+1 949 625-4115 ext. 207 (USA) +64 333
Scott Mohekey wrote:
> What is the relationship between Timestamp and TimestampTz?
TIMESTAMP WITHOUT TIME ZONE does not identify a moment in time without
first associating it with a time zone. When Daylight Saving Time
ends, the same TIMESTAMP WITHOUT TIME ZONE values will recur, without
any
Is it possible to convert from a Timestamp to time_t ? I see functions
mentioned in utils/timestamp.h for converting between TimestampTz and
time_t, but nothing for Timestamp.
What is the relationship between Timestamp and TimestampTz?
Scott Mohekey
Systems/Application Specialist – OnTrack – Telog
20 matches
Mail list logo
