Parece que la respuesta corta a esta pregunta es "No, no es seguro". Esta conclusión sigue a una serie de experimentos con el shell de MySQL. Aún así agradecería una respuesta más "teórica", aunque...
Aparentemente, el motor de MySQL es (por defecto) bastante liberal en lo que acepta como literal de fecha y hora, incluso con sql_mode establecido en STRICT_ALL_TABLES:no solo se aceptan varios separadores, también pueden diferir:
INSERT INTO t(dt) VALUES('2012-01,03.04:[email protected]'); -- Query OK, 1 row affected
Además, si la cadena es demasiado corta, se rellenará con ceros... pero puede haber sorpresas:
INSERT INTO t(dt) VALUES('2012011'); -- 2020-12-01 01:00:00 is what's inserted
Lo triste es que la cadena demasiado larga (cuando el último dígito analizable va seguido de algo que no sea un espacio en blanco) se considerará un valor no válido en modo estricto:
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)
En el modo tradicional, el análisis es aún más relajado, pero no más preciso; además, las cadenas que se consideran incorrectas en el modo estricto darán una especie de 'advertencias silenciosas', aunque las operaciones tendrán éxito:
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 |
+---------------------+
La conclusión es que tuvimos que reescribir algún código relacionado con DAL para que las fechas (y las fechas y horas) siempre se envíen a la base de datos en forma "normalizada". Me pregunto por qué somos nosotros los que tenemos que hacerlo, y no los desarrolladores de Zend_Db. Pero esa es otra historia, supongo. )
