Hi Tom,
Thanks again, I did not appreciate the dual function of "AT TIME ZONE" when
the input is timestamptz then the function converts from one timezone to
another (not what I wanted),
but when the input is timestamp the function acts more like a cast than a
convert (exactly what I wanted)
I
chrisj <[EMAIL PROTECTED]> writes:
> When I first saw your solution I thought it was logically going to do
> (notice the parentheses):
> select ('2006-07-13 09:20:00'::timestamp) at time zone 'EST5EDT';
> which does not help
Well, actually, that's exactly what it does. AT TIME ZONE is an
op
Thanks Tom that's great!!
When I first saw your solution I thought it was logically going to do
(notice the parentheses):
select ('2006-07-13 09:20:00'::timestamp) at time zone 'EST5EDT';
which does not help
So I was not hopeful, but when I tried it it did exactly what I needed which
is:
chrisj <[EMAIL PROTECTED]> writes:
> Did not seem to help:
> ERROR: invalid input syntax for type timestamp with time zone: "2006-07-13
> 09:20:00 America/New_York"
Sorry, I was thinking in terms of CVS HEAD ... the ability to use a full
timezone spec in timestamptz input is new for 8.2. You mig
Did not seem to help:
protocal2=> select start_datetime,cast(cast(cast(start_datetime as
timestamp(0) without time zone) as varchar)||' '||B.timezone_ch as
timestamp(0) with time zone) from reservation A, location B where appt_key
= 7 and locn_key = 102 ;
ERROR: invalid input syntax for type ti
chrisj <[EMAIL PROTECTED]> writes:
> It works fine with fixed offset timezones, but when I try it with EST5EDT
> I get the following:
> ERROR: invalid input syntax for type timestamp with time zone: "2006-07-13
> 09:20:00 EST5EDT"
Try it with "America/New_York". The datetime parser seems to thin
Hi Andrew,
Finally got around to trying to implement your solution.
It works fine with fixed offset timezones, but when I try it with EST5EDT
I get the following:
protocal2=> select start_datetime,cast(cast(cast(start_datetime as
timestamp(0) without time zone) as varchar)||' '||B.timezone_ch as
: Thursday, October 05, 2006 1:02 PM
To: pgsql-sql@postgresql.org
Subject: Re: [SQL] Assigning a timestamp without timezone to a timestamp
Hi Hector,
It would probably better to get the explanation from Andrew, but I will
do
the best I can.
You asked about the 1 and -3. The 1 would be the store
Thanks for the heads up, I definately need EST5EDT
you saved me twice!!
Andrew Sullivan wrote:
>
> On Thu, Oct 05, 2006 at 01:06:00PM -0700, chrisj wrote:
>> If only all time zones were fixed offset timezones life would be so much
>> simpler.
>
> Indeed.
>
>> Unfortunately the main area of
On Thu, Oct 05, 2006 at 01:06:00PM -0700, chrisj wrote:
> If only all time zones were fixed offset timezones life would be so much
> simpler.
Indeed.
> Unfortunately the main area of deployment of my app will beToronto which is
> on EDT which is not a fixed offsets timezone. I hope/assume your s
Hi Andrew,
If only all time zones were fixed offset timezones life would be so much
simpler.
Unfortunately the main area of deployment of my app will beToronto which is
on EDT which is not a fixed offsets timezone. I hope/assume your solution
works with "EDT" instead of "-3", I will test it soo
-03
> 09:00'||"timezone" as timestamp from storetz where id = 1) as a;
>timestamp
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Sullivan
> Sent: Tuesday, October 03, 2006 7:52 AM
> To:
On Wed, Oct 04, 2006 at 11:04:56AM -0700, Hector Villarreal wrote:
> Hi
> I am also interested in this type of setup. However, in the example
> below
> I am a little confused as to why the table entry is 1, -3
The 1 is an artificial key (it's the criterion in the WHERE clause).
The -03 is the t
ber 03, 2006 7:52 AM
To: chrisj
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] Assigning a timestamp without timezone to a timestamp
On Tue, Oct 03, 2006 at 07:26:52AM -0700, chrisj wrote:
> location, but they are the directive to all store locations saying:
"In the
> context of the ti
Hi, Christopher,
christopher wood wrote:
> what is AFAICT ?
"As Far As I Can Tell".
It's explained in the "Jargon File":
http://www.catb.org/jargon/html/A/AFAIK.html
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight aga
Hi Markus,
what is AFAICT ?
In the commercial space, I believe DB2 is one of the best
From: Markus Schaber <[EMAIL PROTECTED]>
Reply-To: PostgreSQL SQL List
To: pgsql-sql@postgresql.org
CC: christopher wood <[EMAIL PROTECTED]>
Subject: Re: [SQL] Assigning a timestamp without t
Hi, Christopher,
christopher wood wrote:
> But I can't even take credit for that, my business partner suggested
> using Postgres.
So I guess he's a smart one, too. :-)
At least as long as he understands that free software does not mean a
TCO of zero dollars, that's the main mistake when busines
t;, pgsql-sql@postgresql.org
Subject: Re: [SQL] Assigning a timestamp without timezone to a timestamp
Date: Wed, 04 Oct 2006 11:07:40 +0200
Hi, Chris,
Hi, Andrew,
Chrisj wrote:
> please be patient with me sometimes I am slow but I usually get there.
Andrew Sullivan wrote:
> Sorry, I&#x
Hi, Chris,
Hi, Andrew,
Chrisj wrote:
> please be patient with me sometimes I am slow but I usually get there.
Andrew Sullivan wrote:
> Sorry, I'm dim,
> Told you I'm dim.
That's just plain wrong. You guys are using PostgreSQL, and that's the
proof that you're the brightest people on the pla
Brilliant, elegant and simple !!
I can't wait to try it (don't have access to Postgres 9-5 EDT) !!
thank-you !!
Andrew Sullivan wrote:
>
> On Tue, Oct 03, 2006 at 07:26:52AM -0700, chrisj wrote:
>> location, but they are the directive to all store locations saying: "In
>> the
>> context of
On Tue, Oct 03, 2006 at 07:26:52AM -0700, chrisj wrote:
> location, but they are the directive to all store locations saying: "In the
> context of the timezone your store is located in, these are the hours you
> should be open.
Ah. Well, then, right, it _does_ have to be timezone free. That's
a
Hi Andrew,
I do appreciate your reply and we agree on two things timestamp without
timezone should be avoided and the timestamps in table 2 should definately
be "with timezone".
I have no problem changing the timestamps in table 1 to "with timezone", but
I do not see how this solves my problem (
On Mon, Oct 02, 2006 at 08:15:56PM -0700, chrisj wrote:
> Two tables both the have open and close columns that are timestamp or
> timestamp with time zone.
I think the best answer is to convert the one table to timestamptz,
and always enter explicitly the time zone with it (since you're going
to k
Hi
Does any one have any ideas for the following problem?
Two tables both the have open and close columns that are timestamp or
timestamp with time zone.
One row in first table represents the corporate office default open and
close times for all stores relative to the store?s own time zone for a
24 matches
Mail list logo
