Hans,
the problem is partially fixed in 4.1.1. You get a warning from inserting a
nonsensical date. But it still accepts '1996-02-31' without a warning,
though there are max 29 days in February. I have now notified the developers
about this bug.
Best regards,
Heikki Tuuri
Innobase Oy
On Fri, Aug 22, 2003 at 01:16:48AM -0500, Hans van Harten wrote:
Rajesh Kumar wrote:
Peter Brawley unknowingly asked us:
Interestingly, use of date_add() and date_sub() on 'odd' dates such
as Feb 31 does produce sane results.
Subtract one from 2000 Feb 31, and you'll get 2000-03-01.
Rajesh Kumar wrote:
Hans van Harten unknowingly asked us:
create database data_test ;
use data_test;
create table test3 (a date);
insert into test3 values (
from_unixtime(unix_timestamp('2002-102-31'),'%Y-%m-%d' ));
insert into test3 values (
On Sat, Aug 23, 2003 at 10:54:32AM +0200, Hans van Harten wrote:
Fred van Engen wrote:
On Fri, Aug 22, 2003 at 01:16:48AM -0500, Hans van Harten wrote:
that comes with neither warnings nor errors reported ...
Error reports would have been nice, but why does your application
supply these
Fred van Engen wrote:
On Sat, Aug 23, 2003 at 10:54:32AM +0200, Hans van Harten wrote:
My checks might not match those of (the next version of) MySQL and
at that time the difference in thoughts will pass unnoticed !
I agree that MySQL should complain but I'm not sure it should fail.
The
On Sat, Aug 23, 2003 at 02:07:36PM +0200, Hans van Harten wrote:
Fred van Engen wrote:
On Sat, Aug 23, 2003 at 10:54:32AM +0200, Hans van Harten wrote:
My checks might not match those of (the next version of) MySQL and
at that time the difference in thoughts will pass unnoticed !
I agree
Rajesh Kumar wrote:
Peter Brawley unknowingly asked us:
Interestingly, use of date_add() and date_sub() on 'odd' dates such
as Feb 31 does produce sane results.
Subtract one from 2000 Feb 31, and you'll get 2000-03-01.
This is sane!!??
This is where Unix Timestamps come into action (and
Hans van Harten unknowingly asked us:
Some make the laughing stock of MySQL with this code:
create database data_test ;
use data_test;
create table test3 (a date);
insert into test3 values (-1);
insert into test3 values ('1996-02-31');
insert into test3 values
: MySQL running out of date
Hans van Harten unknowingly asked us:
Some make the laughing stock of MySQL with this code:
create database data_test ;
use data_test;
create table test3 (a date);
insert into test3 values (-1);
insert into test3 values ('1996-02-31
As per the manual that is correct.
The only correct date will be 1996-02-31.
what is the problem?
-Original Message-
From: Hans van Harten [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 4:09 PM
To: [EMAIL PROTECTED]
Subject: MySQL running out of date
Some make the laughing
Adam Clauss and Rajesh Kumar wrote:
Hans van Harten unknowingly asked us:
LOL
Some make the laughing stock of MySQL with this code:
create database data_test ;
use data_test;
create table test3 (a date);
insert into test3 values (-1);
insert into test3 values
running out of date
Adam Clauss and Rajesh Kumar wrote:
Hans van Harten unknowingly asked us:
LOL
Some make the laughing stock of MySQL with this code:
create database data_test ;
use data_test;
create table test3 (a date);
insert into test3 values (-1);
insert
Interestingly, use of date_add() and date_sub() on 'odd' dates such as
Feb 31 does produce sane results.
Subtract one from 2000 Feb 31, and you'll get 2000-03-01.
This is sane!!??
PB
[mysql]
Kevin Fries wrote:
I agree it's unfortunate that the dates get stored. But some do seem
to prefer it this way.
To quote the manual at the bottom of:
http://www.mysql.com/doc/en/Using_DATE.html
If the date cannot be converted to any reasonable value, a 0 is
stored in the DATE field, which
Peter Brawley unknowingly asked us:
Interestingly, use of date_add() and date_sub() on 'odd' dates such as
Feb 31 does produce sane results.
Subtract one from 2000 Feb 31, and you'll get 2000-03-01.
This is sane!!??
This is where Unix Timestamps come into action (and perhaps rescue)!
To be sure
15 matches
Mail list logo
