Bug #22168 Inserting bad early dates
Submitted: 9 Sep 2006 10:11 Modified: 3 Dec 2007 14:27
Reporter: Georg Richter Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:5.2 OS:Any (all)
Assigned to: Christopher Powers CPU Architecture:Any

[9 Sep 2006 10:11] Georg Richter
Description:
If I insert '0999-01-01' in a DATE column with MyISAM, result = '0999-01-01'.
If I insert '0999-01-01' in a DATE column with Falcon, result = '0000-00-00'.
Yes, the manual says "The supported range is '1000-01-01' to '9999-12-31'".
But it's always been possible to store dates outside the range.

How to repeat:
mysql> create table t21 (s1 date) engine=myisam;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t21 values ('0999-01-01');
Query OK, 1 row affected (0.01 sec)

mysql> select * from t21;
+------------+
| s1 |
+------------+
| 0999-01-01 |
+------------+
1 row in set (0.01 sec)

mysql> create table t22 (s1 date) engine=falcon;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t22 values ('0999-01-01');
Query OK, 1 row affected (0.00 sec)

mysql> select * from t22;
+------------+
| s1 |
+------------+
| 0000-00-00 |
+------------+
1 row in set, 1 warning (0.00 sec)
[18 Sep 2006 18:51] Calvin Sun
Tested on Linux 32-bit change set 1.2276.1.1, 2006-09-04.

'0999-01-01' works
'0001-01-01 00:00:00' does not work.

Added test case falcon_bug_208.test.
[30 Jan 2007 22:16] Ann Harrison
This now works on windows.  I haven't tried it on Suse, but it
doesn't seem like a system related bug.
[31 Jan 2007 1:53] Hakan Küçükyılmaz
Still fails on Linux 32-bit with change set 1.2411, 2007-01-27

Test(s) which will be run though they are marked as disabled:
  falcon_bug_208       : Mantis bug #208 2006-08-24 hakank (Get pushbuild green)

TEST                           RESULT         TIME (ms)
-------------------------------------------------------

falcon_bug_208                 [ fail ]

ERROR: Mantis bug #208 2006-08-24 hakank (Get pushbuild green)
Below are the diffs between actual and expected results:
-------------------------------------------------------
*** r/falcon_bug_208.result     2006-09-05 14:32:31.000000000 +0300
--- r/falcon_bug_208.reject     2007-01-31 04:51:39.000000000 +0300
***************
*** 11,15 ****
  INSERT INTO t1 (b) VALUES ('0001-01-01 00:00:00');
  SELECT count(*) FROM t1 WHERE b = '0001-01-01 00:00:00';
  count(*)
! 1
  DROP TABLE t1;
--- 11,15 ----
  INSERT INTO t1 (b) VALUES ('0001-01-01 00:00:00');
  SELECT count(*) FROM t1 WHERE b = '0001-01-01 00:00:00';
  count(*)
! 0
  DROP TABLE t1;

Regards,

Hakan
[14 Apr 2007 1:07] Hakan Küçükyılmaz
Test is now renamed to falcon_bug_22168.test
[19 Oct 2007 16:18] Kevin Lewis
See also Bug#31490 for another testcase.  It is a duplicate of this.
[22 Oct 2007 6:14] Christopher Powers
This is not a Falcon problem, although the test case will have to be changed.

As stated above, values of type DATE are stored and retrieved correctly.

DATETIME values are also stored and retrieved correctly. 

Falcon stores DATETIME values, e.g. '0001-01-01 01:01:01', as a 64-bit integer. For queries, Falcon faithfully retrieves the 64-bit value then passes it to Field_datetime::store() for conversion back to DATETIME.

As mentioned in Bug#31490, out-of-range years are converted to a current century, so falcon_bug_22168.test must be changed accordingly.

Note that illegal dates are always passed to Falcon as 0, so the date '2007-12-35 01:01:01' will be stored as '0000-00-00 00:00:00'.
[22 Oct 2007 6:16] Christopher Powers
Assigning to Hakan for test case update.
[22 Oct 2007 7:02] Hakan Küçükyılmaz
Test case falcon_bug_22168 passes with MyISAM and InnoDB as storage engine. With Falcon it fails.
[23 Oct 2007 4:18] Christopher Powers
Prior to returning records to the server, Falcon decodes each field from its native format, then passes the value to the corresponding Field::store method. 

The problem with DATETIME values is that Field_datetime::store() converts out-of-range years to a current century, e.g. 0001 becomes 2001. To avoid this, StorageInterface::decodeRecord() now returns values of type DATETIME directly to the server without calling Field_datetime::store().

Changset 1.2670.
[26 Oct 2007 9:58] Kevin Lewis
When testing this fix, Please make sure that the duplicate of this, Bug#31490, is also fixed
[26 Nov 2007 18:10] Hakan Küçükyılmaz
falcon_bug_22168.test is passing now.
[30 Nov 2007 20:43] Bugs System
Pushed into 6.0.4-alpha
[3 Dec 2007 14:27] MC Brown
A note has been added to the 6.0.4 changelog: 

Creating a DATE outside the normal range within a Falcon table would result in a zero DATE value being returned, even though normally invalid values would be stored correctly in other storage engines.