问题
In our project we use Zend Framework Model generator, which produces something like this to set the properties that are stored in DB (MySQL) as DATETIME fields:
public function setObjectDatetime($data) {
if (! $data instanceof Zend_Date) { ... some conversion code ... }
$this->objectDatetime = $data->toString(Zend_Date::ISO_8601);
}
So the ISO::8601 formatted string ('2012-06-15T18:33:00+03:00' for example) is what actually is stored as a property.
The problem arises when we try to save this model, and pass this string to MySQL (version 5.5.16): it raise the warning, but still inserts/updates the corresponding row with a correct result. It's easy to check that the issue is caused by MySQL, and not some drivers' behaviour: just issue such query as...
UPDATE table_name SET datetime_field = '2012-06-15T18:33:00+03:00' WHERE id = 1;
... and the result will be 1 row affected, 1 warning, with
1264 | Out of range value for column 'dt' at row 1
warning (shown by SHOW WARNINGS).
To my amuzement, phpMyAdmin doesn't show any warnings at all; and all the server-side code processed this query as a solid one. )
So the question is: should we really reformat what we store in our Model into another string format ('YY-MM-dd HH:mm:ss', for example?) Or is it just some weird behavior of MySQL that will be fixed sooner or later?
回答1:
It looks like the short answer to this question is "No, it's not safe" - this conclusion follows a series of experiments with MySQL shell. Still would appreciate a more "theoretical" answer, though...
Apparently MySQL engine is (by default) pretty liberal in what it accepts as a Datetime literal even with sql_mode set to STRICT_ALL_TABLES : not only various separators are accepted, they may differ as well:
INSERT INTO t(dt) VALUES('2012-01,03.04:05@06'); -- Query OK, 1 row affected
Besides, if the string is too short, it will be padded with zeroes... but there might be surprises:
INSERT INTO t(dt) VALUES('2012011'); -- 2020-12-01 01:00:00 is what's inserted
The sad thing is that the string too long (when the last parsable digit is followed by something other than whitespace) will be considered an invalid value in strict mode:
mysql> INSERT INTO t(dt) VALUES('2012-06-27T05:25Z');
ERROR 1292 (22007): Incorrect datetime value: '2012-06-27T05:25Z' for column 'dt' at row 1
mysql> INSERT INTO t(dt) VALUES('2012-06-27T05:25');
Query OK, 1 row affected (0.10 sec)
In the traditional mode parsing is even more relaxed - but not more precise; besides, the strings that are considered incorrect in the strict mode will give sort of 'silent warnings', though operations will succeed:
mysql> INSERT INTO t(dt) VALUES('2012-06-27T05:25Z');
Query OK, 1 row affected, 1 warning (0.10 sec)
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------------+
| Warning | 1264 | Out of range value for column 'dt' at row 1 |
+---------+------+---------------------------------------------+
mysql> SELECT dt FROM t;
+---------------------+
| dt |
+---------------------+
| 2012-06-27 05:25:00 |
+---------------------+
The bottom line is that we had to rewrite some DAL-related code so that dates (and datetimes) are always sent to the DB in "normalized" form. I wonder why it's we who have to do it, and not Zend_Db developers. But that's another story, I suppose. )
回答2:
As far as I know there is no way to store time offset information (the +03:00 at the end of your ISO 8601 string) in MySQL Date or Time types, so you're sort of on your own to find a solution.
One possible approach is to split the ISO 8601 string and store the offset in a char(5) column, though admittedly it would make it sort of difficult to work with. I suppose you could store the offset in a Time column, which might make date/time manipulations a little bit easier.
EDIT
I just stumbled upon this in the MySQL docs, which may be helpful.
回答3:
By default MySQL use ISO9075 format for datetime
The possible values for the first and second arguments result in several possible format strings (for the specifiers used, see the table in the DATE_FORMAT() function description). ISO format refers to ISO 9075, not ISO 8601.
http://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_get-format
来源：https://stackoverflow.com/questions/11053941/mysql-insert-to-datetime-is-it-safe-to-use-iso8601-format