Possiamo invece farlo:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
Il FROM_UNIXTIME la funzione è limitata dall'intervallo consentito per il TIMESTAMP tipo di dati, che è l'intervallo di int senza segno a 32 bit standard dal 1970-01-01 al 2038-01-qualcosa. Altro software è stato aggiornato per supportare interi con segno a 64 bit, ma MySQL non fornisce ancora quella funzionalità (almeno non in 5.1.x).
La soluzione alternativa in MySQL è evitare di usare il TIMESTAMP tipo di dati e utilizzando il DATETIME datatype invece, quando abbiamo bisogno di un intervallo più ampio (ad es. date prima del 1 gennaio 1970).
Possiamo usare il DATE_ADD funzione per sottrarre secondi dal 1 gennaio 1970, in questo modo:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
NB Probabilmente dovrai tenere conto degli "offset" del fuso orario dall'UTC per eseguire questi tipi di calcoli. MySQL interpreterà i valori DATETIME come specificati nel time_zone impostazione della sessione MySQL corrente, anziché UTC (time_zone = '+00:00' )
SEGUITO:
D: Ok, significa che se selezioniamo date inferiori a "1970-01-01 00:00:00", il valore negativo viene salvato nel db, altrimenti sarebbe positivo. Giusto? – softgenic
R: Ehm, no. Se selezioni i valori di data/data e ora prima del 1 gennaio 1970, MySQL restituirà i valori DATE o DATETIME prima del 1 gennaio 1970. Se memorizzi i valori DATE o DATETIME prima del 1 gennaio 1970, MySQL memorizzerà il valore DATE o DATETIME prima del 1 gennaio , 1970, entro l'intervallo consentito supportato da tali tipi di dati. (qualcosa come da 0001-01-01 a 9999?)
Se hai bisogno di memorizzare numeri interi positivi e negativi davvero molto grandi nel database, probabilmente li memorizzeresti in una colonna definita come BIGINT .
La rappresentazione interna di una colonna DATE richiede 3 byte di memoria e DATETIME richiede 8 byte di memoria (fino alla versione MySQL 5.6.4. La rappresentazione interna e la memorizzazione dei valori DATE e DATETIME sono state modificate in 5.6.4)
Quindi no, MySQL non memorizza i valori di data prima del 1970 come "interi negativi".
Se ci pensi un po', MySQL è libero di implementare qualsiasi meccanismo di archiviazione desideri. (E ogni motore di archiviazione è libero di serializzare quella rappresentazione su disco come vuole.)
Perché 3 byte per una data?
Un'opzione che MySQL ha (e non sto dicendo che questo è il modo in cui è fatto) potrebbe essere quella di suddividere la data nei componenti del mese e del giorno dell'anno.
La rappresentazione di valori interi nell'intervallo - richiede -
-
0 - 9999 -14 bit -
0 - 12 -4 bit -
0 - 31 -5 bit
Questo è un totale di 23 bit, che si adatta facilmente a 3 byte. Questo dimostra solo che non è necessario che MySQL rappresenti i valori di data prima del 1 gennaio 1970 come numeri interi negativi, quindi non dovremmo presumere che lo faccia. (Ma ci preoccuperemmo davvero solo di questo livello di dettaglio se stessimo lavorando su un motore di archiviazione per MySQL.)
