Es sieht so aus, als ob die kurze Antwort auf diese Frage "Nein, es ist nicht sicher" lautet - diese Schlussfolgerung folgt einer Reihe von Experimenten mit der MySQL-Shell. Trotzdem würde ich mich über eine "theoretischere" Antwort freuen ...
Anscheinend ist die MySQL-Engine (standardmäßig) ziemlich liberal in dem, was sie als Datetime-Literal akzeptiert, sogar mit sql_mode auf STRICT_ALL_TABLES gesetzt:Es werden nicht nur verschiedene Trennzeichen akzeptiert, sie können sich auch unterscheiden:
INSERT INTO t(dt) VALUES('2012-01,03.04:[email protected]'); -- Query OK, 1 row affected
Wenn der String zu kurz ist, wird er außerdem mit Nullen aufgefüllt... aber es könnte Überraschungen geben:
INSERT INTO t(dt) VALUES('2012011'); -- 2020-12-01 01:00:00 is what's inserted
Das Traurige daran ist, dass eine zu lange Zeichenfolge (wenn auf die letzte parsbare Ziffer etwas anderes als Leerzeichen folgt) im strikten Modus als ungültiger Wert betrachtet wird:
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)
Im traditionellen Modus ist das Parsing noch entspannter - aber nicht präziser; Außerdem geben die Zeichenfolgen, die im strengen Modus als falsch angesehen werden, eine Art 'stille Warnung', obwohl die Operationen erfolgreich sind:
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 |
+---------------------+
Das Fazit ist, dass wir einen DAL-bezogenen Code neu schreiben mussten, damit Daten (und Datumszeiten) immer in „normalisierter“ Form an die DB gesendet werden. Ich frage mich, warum wir das tun müssen und nicht Zend_Db-Entwickler. Aber das ist eine andere Geschichte, nehme ich an. )
