conversión implícita a partir de ahora () para un campo de fecha

Question

Tengo un problema con MySQL 5.1. Un tipo de datos de fecha y hora no es fundido de manera implícita para que coincida con una columna de fecha.

 SELECT * FROM my_table WHERE my_date_field = NOW()

Esta solicitud no devuelve ninguna fila utilizando MySQL 5.1, pero funciona bien con la versión 5.0. Si utilizamos CURDATE() en lugar de NOW() funciona tanto en MySQL 5.0 y MySQL 5.1. Si el yeso es explícito (CAST(NOW() AS DATE)), también funciona tanto en MySQL 5.0 y MySQL 5.1.

El problema sólo aparece con conversión implícita de fecha y hora hasta la fecha. ¿Nadie ha encontrado ya este problema o tiene una idea acerca de cómo resolver este problema? Yo sé que no es el mejor para usar NOW () en lugar de CURTIME (), pero esta no es la cuestión aquí. Actualmente se utiliza en una aplicación y el propósito es evitar volver a escribir todo.

Gracias!

Answer 1

Esto se fijó en MySQL 5.1. 17 para permitir CURDATE () para evaluar al menos de NOW () cuando se almacena en una columna DATE.

Ahora, al comparar una fecha para una fecha y hora, se comparan como fecha y hora. Cuando una fecha es arrojado a una fecha y hora, tiene una hora cero.

Si es my_date_field '2010-01-01' Y NOW() es '2010-01-01 05:01:01', cuando se comparan, my_date_field es ascendido a '2010-01-01 00:00:00', que es obviamente menos que '2010-01-01 05:01:01'.

En un principio, cuando el lado izquierdo era una columna, la promoción de DATE a DATETIME no se produjo. Sin embargo, al parecer pensaron que era más consistente para promover siempre la misma.

Lo sentimos, pero sólo tuvo suerte de que haya funcionado antes. Una fecha que tiene una hora cero debe evaluar a menos que el mismo día con un no-cero horas.

Desafortunadamente, no hay manera de desactivar esta "corrección de errores". Su única solución es cambiar NOW () para CURDATE () o hacia atrás rollo a una versión anterior.

En realidad, se puede compilar su propia versión y, o bien deshacer la "corrección de errores" o reemplazar la función NOW ().

Answer 2

El comportamiento tiene sentido porque es NOW() del DATETIME tipo y CURDATE() del DATE tipo.

En cuanto a por qué las variables se echan en una versión de servidor y no en el otro - esto suena más como una diferencia en la modos de servidor , es decir, el caso en el que el molde no ser más estricto que el otro.

Un punto interesante de ese documento (no estoy seguro de si este es su problema, pero podría ser): ALLOW_INVALID_DATES :

  

Este modo se implementa en MySQL 5.0.2. Antes de 5.0.2, este fue el modo de la fecha de manejo de defecto de MySQL. A partir de 5.0.2, el servidor requiere que el mes y día los valores son legales, y no sólo en el rango de 1 a 12 y de 1 a 31, respectivamente. Con el modo estricto desactivado, pero ilegal como '31/04/2004' se convierten en '0000-00-00' y se genera una advertencia. Con el modo estricto activado, las fechas no válidos generan un error. Para permitir este tipo de fechas, permitirá ALLOW_INVALID_DATES.

De todos modos, no estoy seguro de si tiene sentido excavación a través de registros de cambios tratando de averiguar lo que cambió cuando. Yo tendería a hacer que el comportamiento en ambas situaciones (es decir, si he entendido bien, CURDATE() uso) y hacerse con él.

Answer 3

Sólo comparar la fecha de su parte la columna de fecha y hora:

SELECT * FROM my_table WHERE DATE(my_date_field) = DATE(NOW())