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: | |
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
[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.