Scott Mohekey scott.mohe...@telogis.com 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
On Tue, Sep 15, 2009 at 09:23:09AM -0500, Kevin Grittner wrote:
Scott Mohekey scott.mohe...@telogis.com 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
David Fetter da...@fetter.org 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()?
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov 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
On Tue, Sep 15, 2009 at 11:02:52AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
David Fetter da...@fetter.org 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
Andrew Gierth and...@tao11.riddles.org.uk wrote:
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov
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
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 datetime value
expression. If extract
David E. Wheeler da...@kineticode.com 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
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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andrew Gierth and...@tao11.riddles.org.uk 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
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov 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
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
Tom Lane t...@sss.pgh.pa.us 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
Andrew Gierth and...@tao11.riddles.org.uk 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
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
On Wed, Sep 16, 2009 at 2:23 AM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Scott Mohekey scott.mohe...@telogis.com 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.
Scott Mohekey scott.mohe...@telogis.com 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
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
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 –
20 matches
Mail list logo
