Vypadá to, že krátká odpověď na tuto otázku je „Ne, není to bezpečné“ – tento závěr následuje po sérii experimentů s MySQL shellem. Přesto bych ocenil více "teoretickou" odpověď, i když...
Engine MySQL je zjevně (ve výchozím nastavení) docela liberální v tom, co přijímá jako doslovný datetime i s sql_mode nastaveno na STRICT_ALL_TABLES :jsou přijímány nejen různé oddělovače, ale mohou se také lišit:
INSERT INTO t(dt) VALUES('2012-01,03.04:[email protected]'); -- Query OK, 1 row affected
Kromě toho, pokud je řetězec příliš krátký, bude doplněn nulami... ale může dojít k překvapení:
INSERT INTO t(dt) VALUES('2012011'); -- 2020-12-01 01:00:00 is what's inserted
Smutné je, že příliš dlouhý řetězec (když za poslední analyzovatelnou číslicí následuje něco jiného než mezera) bude v přísném režimu považován za neplatnou hodnotu:
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)
V tradičním režimu je analýza ještě uvolněnější - ale ne přesnější; kromě toho řetězce, které jsou v přísném režimu považovány za nesprávné, budou vydávat jakési „tiché varování“, ačkoli operace budou úspěšné:
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 |
+---------------------+
Pointa je, že jsme museli přepsat nějaký kód související s DAL tak, aby se data (a datum a čas) vždy posílala do DB v "normalizované" podobě. Zajímalo by mě, proč to musíme dělat my, a ne vývojáři Zend_Db. Ale to je, předpokládám, jiný příběh. )