MySQL insert to DATETIME: is it safe to use ISO::8601 format?

Question

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:

Answer 1

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

Answer 2

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. )

Answer 3

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.