You are both right.
Your explanation, Steve, was the light that got me going on a simpler
solution along the lines of what Tom suggested. I didn't really need
AGE, and upon digging in, couldn't even remember why I had chosen that
in the first place.
Postgres is the bomb!
Thanks guys.
Steve Crawfor
On Wednesday 03 March 2004 3:19 pm, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > US Daylight Saving Time starts this year on April 4 when 0200
> > jumps to 0300. The answers PostgreSQL gave are correct.
>
> I suspect what the OP wants is non-timezone-aware behavior...
You are p
Steve Crawford <[EMAIL PROTECTED]> writes:
> US Daylight Saving Time starts this year on April 4 when 0200 jumps to
> 0300. The answers PostgreSQL gave are correct.
I suspect what the OP wants is non-timezone-aware behavior, which he
could get by casting the inputs of age() to timestamp without t
On Wednesday 03 March 2004 9:19 am, DHS Webmaster wrote:
> We began encountering some unexpected date related errors this
week...
> This is good...
> network=# select age('04-01-04','03-01-04');
> age
> ---
> 1 mon
> (1 row)
>
> This isn't...
> network=# select age('05-01-04','03-01-04');
Hello all,
Many thanks for this fine product.
We began encountering some unexpected date related errors this week and
after further investigation found the following. We use the postgres AGE
function in a custom function. The AGE function has begun to throw some
unanticipated results back. This has
