Het lijkt erop dat het korte antwoord op deze vraag "Nee, het is niet veilig" is - deze conclusie volgt op een reeks experimenten met MySQL-shell. Toch zou een meer "theoretisch" antwoord op prijs worden gesteld...
Blijkbaar is de MySQL-engine (standaard) behoorlijk liberaal in wat het accepteert als een Datetime-letterlijk, zelfs met sql_mode ingesteld op STRICT_ALL_TABLES:niet alleen verschillende scheidingstekens worden geaccepteerd, ze kunnen ook verschillen:
INSERT INTO t(dt) VALUES('2012-01,03.04:[email protected]'); -- Query OK, 1 row affected
Trouwens, als de string te kort is, wordt deze opgevuld met nullen... maar er kunnen verrassingen zijn:
INSERT INTO t(dt) VALUES('2012011'); -- 2020-12-01 01:00:00 is what's inserted
Het trieste is dat de string die te lang is (wanneer het laatste parseerbare cijfer wordt gevolgd door iets anders dan witruimte) in de strikte modus als een ongeldige waarde wordt beschouwd:
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 de traditionele modus is het ontleden nog meer ontspannen - maar niet nauwkeuriger; bovendien zullen de tekenreeksen die in de strikte modus als onjuist worden beschouwd een soort 'stille waarschuwingen' geven, hoewel de bewerkingen zullen slagen:
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 |
+---------------------+
Het komt erop neer dat we een aantal DAL-gerelateerde code moesten herschrijven, zodat datums (en datetimes) altijd in "genormaliseerde" vorm naar de DB worden verzonden. Ik vraag me af waarom wij het zijn die het moeten doen, en niet de Zend_Db-ontwikkelaars. Maar dat is een ander verhaal, denk ik. )