2012-07-30 7 views
10

He ingresado manualmente (GASP!) Un comando MySQL en la línea de comando, y recibí una Advertencia que ni siquiera puedo comenzar a entender. (Y antes de que alguien diga algo, sí, SÉ: 1. Usar la interfaz de línea de comando no es el mejor enfoque; 2. Mi tabla NO se llama "TABLE_NAME" y mi columna NO se llama "DateColumn" y mi valor de RecordID NO es realmente "1234"; 3. Tal vez mi columna de tipo debe ser TIMESTAMP, pero por ahora, no se está moviendo en ....)Strange MySQL warning 1264 para valid DateTime value

se intenta introducir un valor para la fecha "Julio 26to 2012 a 2. : 27 PM (GMT)", que por clave:

mysql> update TABLE_NAME set DateColumn="2012-07-26 14:27:00" where RecordID="1234"; 

recibí:

Query OK, 1 row affected, 1 warning (0.11 sec) 
Rows matched: 1 Changed: 1 Warnings: 1 

Entonces, tecleé:

mysql> show warnings; 
+---------+------+-----------------------------------------------------+ 
| Level | Code | Message            | 
+---------+------+-----------------------------------------------------+ 
| Warning | 1264 | Out of range value for column 'DateColumn' at row 1 | 
+---------+------+-----------------------------------------------------+ 

Extraño, pensé. Así que he comprobado la mesa primero para confirmar la columna (campo) tipo:

mysql> describe TABLE_NAME; 

+------------+----------+------+-----+-------------------+-------+ 
| Field  | Type  | Null | Key | Default   | Extra | 
| DateColumn | datetime | YES |  | NULL    |  | 
+------------+----------+------+-----+-------------------+-------+ 

pero el valor no se escriben correctamente a la base de datos, y no truncada, que yo sepa:

mysql> select * from TABLE_NAME where RecordID="1234"; 

+-----------------------------------------------+ 
| RecordID | Date_Column   | BlahBlahBlah | 
+----------+---------------------+--------------+ 
|  1234 | 2012-07-26 14:27:00 | something.. | 
+----------+---------------------+--------------+ 

ya he buscó StackOverflow.com para una solución. Ya busqué en Google una explicación. Ya he leído arriba en http://dev.mysql.com/doc/refman/5.5/en/datetime.html donde dice:

MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. 

que incluso tenía una ligera sospecha de que tenía algo que ver con la fecha o la hora en la que yo estaba haciendo la entrada; así que declararé que el servidor en el que se encuentra la base de datos está en Pacific Daylight Time (GMT-8, excepto ahora GMT-7 para DST); Estoy conectado (SSH) desde un cliente en EDT (que no debería importar); y estoy almacenando todos los valores de Date_Column como GMT. En el momento en que estaba ingresando el valor "2012-07-26 14:27:00" las tres fechas estaban bien DESPUÉS, el 30/7/12. No es que importe - I debería ser capaz de ingresar fechas futuras sin obtener un error, pero pensó que podría ser útil para usted saber. Entonces,

WHY, OH WHY es "2012-07-26 14:27:00" un valor fuera del rango?

Mi versión de API de cliente MySQL es 5.1.49.

Esta es la primera vez que publico en StackOverflow. Gracias de antemano por sus sugerencias.

+0

"El rango admitido es '1000-01-01 00:00:00' a '9999-12-31 23:59:59'." Así que no veo ningún problema con su valor ... – Jocelyn

+0

¿Qué versión de MySQL está ejecutando? – Throdne

+0

@Throdne mysql> seleccionar versión(); version() 5.1.56-log – user1564318

Respuesta

3

Me pregunto si se está convirtiendo a algún formato de fecha de la cadena. Ese formato de fecha tendría entonces demasiada precisión que se truncaría. Intente enviarlo a una fecha y hora antes de asignarlo.

+0

Gracias, intentaré eso. Mientras tanto: The Warning no decía nada acerca de truncar, solo que el valor estaba "fuera de rango". (Stumped.) – user1564318

+0

ESTO FUNCIONÓ - ¡SIN ADVERTENCIAS! mysql> actualiza TABLE_NAME establecido DateColumn = CAST ("2012-07-26 14:27:00" AS DATETIME) donde RecordID = "1234"; Pregunta OK, 1 hilera afectada (0.07 seg) Filas coincidentes: 1 Modificado: 1 Advertencias: 0 Todavía no entiendo por qué importaba, por qué la "precisión" era diferente. Pero gracias @Markus – user1564318