> 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
11 matches
Mail list logo
