Por ejemplo, la siguiente consulta funciona bien:MySQL comparación de fecha y hora
SELECT *
FROM quotes
WHERE expires_at <= '2010-10-15 10:00:00';
Pero esto es, obviamente, realizando una comparación 'cadena' - Me preguntaba si había una función integrada en MySQL que hace específicamente 'fecha y hora' comparaciones
... esto es, obviamente, la realización de una 'cadena' de comparación
No - si el formato de fecha/hora coincide con el formato compatible, MySQL realiza la conversión implícita para convertir el valor a una fecha y hora , basado en la columna con la que se compara. Lo mismo sucede con:
WHERE int_column = '1'
... donde el valor de cadena de "1" se convierte en un entero porque el tipo de datos int_column 's es INT, no CHAR/VARCHAR/TEXTO.
Si desea convertir explícitamente la cadena a una fecha y hora, la STR_TO_DATE function sería la mejor opción:
WHERE expires_at <= STR_TO_DATE('2010-10-15 10:00:00', '%Y-%m-%d %H:%i:%s')
Pero esto es, obviamente, realizando una comparación 'cadena'
No. La cadena serán arrojados de forma automática en un valor de fecha y hora.
Ver 11.2. Type Conversion in Expression Evaluation.
Cuando un operador se utiliza con operandos de diferentes tipos, la conversión de tipo ocurre para hacer compatible los operandos. Algunas conversiones ocurren implícitamente. Por ejemplo, MySQL convierte automáticamente los números en cadenas según sea necesario, y viceversa.
Sé que es bastante viejo pero acabo de encontrar el problema y no es lo que vi en el SQL doc:
[Para obtener mejores resultados al usar BETWEEN con valores de fecha u hora,] utilice CAST() para convertir explícitamente los valores al tipo de datos deseado. Ejemplos: si compara un DATETIME con dos valores de DATE, convierta los valores de DATE a DATETIME. Si usa una constante de cadena como '2001-1-1' en una comparación con una FECHA, transfiera la cadena a una FECHA.
supongo que es mejor utilizar STR_TO_DATE desde que tomaron el tiempo para hacer una función sólo para eso y también el hecho de que he encontrado esto en el doc ... ENTRE
Si su servidor o cadenas no son en UTC, tenga cuidado ya que la conversión implícita ocurre con el servidor/sesiones time_zone, no la zona horaria del valor con el que se compara. Entonces la cadena es el mismo time_zone local incluso si lo compara con UTC_TIMESTAMP(). – ClearCrescendo
@ClearCrescendo: Buen punto, gracias. –