2012-07-30 6 views
10

Ho manualmente (GASP!) Immesso un comando MySQL alla riga di comando e ho ricevuto un avviso che non riesco nemmeno a capire. (E prima che qualcuno dica qualcosa, sì, SO: 1. L'uso dell'interfaccia a riga di comando non è l'approccio migliore; 2. La mia tabella NON è denominata "TABLE_NAME" e la mia colonna NON è denominata "DateColumn" e il mio valore RecordID NON è davvero "1234"; 3. Forse la mia colonna di tipo dovrebbe essere TIMESTAMP, ma per ora, non si muove su ....)Strange avviso MySQL 1264 per valore DateTime valido

il tentativo di immettere un valore per la data "26 luglio 2012 a 2. : 27 PM (GMT)", ho digitato:

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

che ho ricevuto:

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

Quindi, ho digitato:

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

Strano, ho pensato. Così ho controllato il tavolo prima di confermare la colonna (campo) tipo:

mysql> describe TABLE_NAME; 

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

ma il valore fa arrivare scritto correttamente al database, e non troncato, per quanto ne so:

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

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

ho già cercato StackOverflow.com per una soluzione. Ho già cercato su Google una spiegazione. Ho già letto fino a http://dev.mysql.com/doc/refman/5.5/en/datetime.html in cui si 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'. 

ho anche avuto un leggero sospetto che aveva a che fare con la data o l'ora in cui stavo facendo l'entrata; quindi affermerò che il server su cui si trova il database è in Pacific Daylight Time (GMT-8, eccetto ora GMT-7 per DST); Sono loggato (SSH) da un client su EDT (che non dovrebbe avere importanza); e sto memorizzando tutti i valori Date_Column come GMT. All'epoca stavo inserendo il valore "2012-07-26 14:27:00" tutte e tre le date sono andate bene DOPO questo, il 30/07/12. Non importa che dovrebbe importare - I è possibile immettere le date future senza ricevere un errore, ma pensavo che potrebbe essere utile per te sapere. Quindi -

PERCHÉ, OH WHY è "2012-07-26 14:27:00" un valore fuori intervallo?

La mia versione dell'API del client MySQL è 5.1.49.

Questa è la prima volta che ho pubblicato su StackOverflow. Grazie in anticipo per i tuoi suggerimenti.

+0

"L'intervallo supportato è" 1000-01-01 00:00:00 "su" 9999-12-31 23:59:59 "." Quindi non vedo un problema con il tuo valore ... – Jocelyn

+0

Quale versione di MySQL stai usando? – Throdne

+0

@Throdne mysql> select version(); versione() 5.1.56-log – user1564318

risposta

3

Mi chiedo se si sta convertendo in un formato data da stringa. Quel dataformat avrebbe quindi troppa precisione che sarebbe troncata. Prova a trasmetterlo a un datetime prima di assegnarlo.

+0

Grazie, ci proverò. Nel frattempo: L'avvertimento non ha detto nulla sul troncamento, solo che il valore era "fuori portata". (Stumped.) – user1564318

+0

QUESTO FUNZIONA - NESSUNA AVVERTENZA! mysql> update TABLE_NAME set DateColumn = CAST ("2012-07-26 14:27:00" AS DATETIME) dove RecordID = "1234"; Query OK, 1 righe interessate (0,07 sec) Righe corrispondenti: 1 Modificato: 1 Avvisi: 0 Ancora non capisco perché è importante, perché la "precisione" è diversa. Ma grazie @Markus – user1564318