Skip site navigation (1) Skip section navigation (2)

Re: 6.5.0 datetime bug?

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: gravity(at)dds(dot)nl
Cc: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 6.5.0 datetime bug?
Date: 2000-03-31 15:37:36
Message-ID: 38E4C640.3B4907F0@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > Hmm, I happen to have a 6.5.0 system sitting here: It works there, so I suspect
> > something with your local operating system config.
> anyone?

It turns out to be a problem in the local country config :)

Why does the Netherlands (or at least my RH5.2 timezone database)
think you switch to DST on March 26? The date_part() function was just
masking the problem:

postgres=# select '3-27-2000'::timestamp-'3-6-2000'::timestamp;
 ?column? 
----------
 20 23:00
(1 row)

postgres=# select '3-26-2000'::timestamp-'3-6-2000'::timestamp;
 ?column? 
----------
 20 00:00
(1 row)

When you do the date arithmetic, you are automatically calculating an
*absolute* time difference which can be affected by DST boundaries.

For some reason, we don't have a date_part() available for the date
data type, which would have been my suggested workaround. We'd flame
the implementer, but that's me so I'll be nice :(

It is probably too late to get this added for v7.0, though I might be
able to add the code to the backend so it could be a (very) small
CREATE FUNCTION operation to get it usable for 7.0. Will look at it.

                         - Thomas

-- 
Thomas Lockhart				lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

pgsql-hackers by date

Next:From: Maarten BoekholdDate: 2000-03-31 15:38:03
Subject: Re: 6.5.0 datetime bug?
Previous:From: Karel ZakDate: 2000-03-31 15:33:29
Subject: procedure returns a tuple

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group