Thanks for the reply Tom Lane, and Tom Lockhart. On my 7.0.3:
phil=# select '4/1/2001'::date::timestamp;
?column?
2001-03-31 23:00:00-08
(1 row)
This was built from source downloaded from the primary FTP site link
on www.postgresql.org.
[cartret@Sti
[EMAIL PROTECTED] writes:
> edge=# select date_part('dow','4/1/2001'::date)::int4;
> ?column?
> --
> 6
> (1 row)
Seems to be fixed in current sources:
regression=# select date_part('dow','4/1/2001'::date)::int4;
?column?
--
0
(1 row)
I think this is a side-ef
Query to reproduce the bug (7.0.3):
edge=# select date_part('dow','9/1/2001'::date)::int4;
?column?
--
6
(1 row)
edge=# select date_part('dow','4/1/2001'::date)::int4;
?column?
--
6
(1 row)
Clearly, the first of April and September are not both on the same
"Alexandru COSTIN" <[EMAIL PROTECTED]> writes:
> I've discovered a bug in the date_part function. It returns 25 when
> doing select date_part('day','2000-03-26'::date);
Is 2000-03-26 a daylight savings changeover day where you live?
If so, this is a known bug that's fixed for 7.1. date_part
[ Charset ISO-8859-1 unsupported, converting... ]
> Hello,
> I've discovered a bug in the date_part function. It returns 25 when
> doing select date_part('day','2000-03-26'::date);
> Anyway, this isn't happening if casting the date to timestamp
> select date_part('day','2000-03-26'
Hello,
I've discovered a bug in the date_part function. It returns 25 when
doing select date_part('day','2000-03-26'::date);
Anyway, this isn't happening if casting the date to timestamp
select date_part('day','2000-03-26'::timestamp);
Alexander
> Seems like you could just skip step 3 and call localtime() with fields
> indicating midnight of the specified date. Then use the complete
> localtime result (don't discard any fields) and you should be OK, no?
OK, I have a solution which involves mktime(). As a side effect, I've
stripped some
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Seems like you could just skip step 3 and call localtime() with fields
>> indicating midnight of the specified date. Then use the complete
>> localtime result (don't discard any fields) and you should be OK, no?
> Pretty sure this won't work, since
> Seems like you could just skip step 3 and call localtime() with fields
> indicating midnight of the specified date. Then use the complete
> localtime result (don't discard any fields) and you should be OK, no?
Pretty sure this won't work, since the complete localtime result will
not be local m
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Looks to me like an off-by-one kind of problem in deciding which
> timezone applies to midnight of a transition day.
> 2) Convert to an integer "Unix system time".
> 3) Rotate by 12 hours (to UTC noon!). This is supposed to ensure that we
> s
> >> Looks to me like an off-by-one kind of problem in deciding which
> >> timezone applies to midnight of a transition day.
> > The date->timestamp conversion code gets this right, so you might want
> > to look at that.
> Au contraire: the cited examples appear to prove that the
> date->timestamp
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Looks to me like an off-by-one kind of problem in deciding which
>> timezone applies to midnight of a transition day.
> The date->timestamp conversion code gets this right, so you might want
> to look at that.
Au contraire: the cited examples appear
> > it's not date_part() bug, it's to_date() bug:
> Looks to me like an off-by-one kind of problem in deciding which
> timezone applies to midnight of a transition day.
Probably a bit worse (but no problem to solve ;): you need to make sure
that you rotate the date type to the correct time z
>
> Looks to me like an off-by-one kind of problem in deciding which
> timezone applies to midnight of a transition day.
>
> regards, tom lane
Hmm ... really cool solution. You are right! I was sure that in the my
to_() code can't be bug :-))
Thanks.
Karel Zak <[EMAIL PROTECTED]> writes:
> it's not date_part() bug, it's to_date() bug:
> test=# select to_date('26.03.2000','dd.mm.')::timestamp;
> ?column?
>
> 2000-03-25 23:00:00+01
> ^^^
>! Bug !
> test=# select to_timestamp('2
> Sample Code
> create table oops (date date);
>
> insert into oops (date) values (to_date('24.03.2000','dd.mm.'));
> insert into oops (date) values (to_date('25.03.2000','dd.mm.'));
> insert into oops (date) values (to_date('26.03.2000','dd.mm.'));
> insert into oops (date) values (t
Alex Karpov ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
bug in date_part() function in 6.5.2, 7.0.2
Long Description
Checked on Postgres version 6.5.2 and 7.0.2:
Incorrect DOW and DAY parts of date calculation. See exanple
17 matches
Mail list logo
