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:

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?

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