Per l'esempio specifico che hai utilizzato per la tua domanda (anno 1200), tecnicamente le cose funzioneranno.
In generale, tuttavia, i timestamp sono sconsigliabili per questi usi. Innanzitutto, la limitazione dell'intervallo è arbitraria:in MySQL è il 1 gennaio 1000. Se stai lavorando con cose del 12-13° secolo, le cose vanno bene... ma se a un certo punto devi aggiungere qualcosa di più vecchio (X secolo o prima), la data si interromperà miseramente e la risoluzione del problema richiederà la riformattazione di tutte le tue date storiche in qualcosa di più adeguato.
I timestamp sono normalmente rappresentati come numeri interi grezzi, con un dato "tick interval" e "epoch point", quindi il numero è infatti il numero di tick trascorsi dall'epoca alla data rappresentata (o viceversa per date negative). Ciò significa che, come con qualsiasi tipo di dati fisso con intero, l'insieme di valori rappresentabili è finito. Conosco la maggior parte dei formati di timestamp sull'intervallo di sacrificio a favore della precisione, principalmente perché le applicazioni che devono eseguire l'aritmetica temporale spesso devono farlo con una precisione decente; mentre le applicazioni che devono funzionare con date storiche molto raramente devono eseguire operazioni aritmetiche serie.
In altre parole, i timestamp sono pensati per precisi rappresentazione delle date. La precisione della seconda (o anche frazione di secondo) non ha senso per le date storiche:potresti dirmi, fino al millisecondo, quando Enrico VIII fu incoronato re d'Inghilterra?
Nel caso di MySQL, il formato è intrinsecamente definito come "anni a 4 cifre", quindi qualsiasi ottimizzazione correlata può basarsi sul presupposto che l'anno avrà 4 cifre o che l'intera stringa avrà esattamente 10 caratteri ("yyyy- mm-dd"), ecc. È solo una questione di fortuna che la data che hai menzionato sul tuo titolo sia ancora adatta, ma anche fare affidamento su quella è comunque pericoloso:oltre a ciò che il DB stesso può memorizzare, devi essere consapevole di ciò che il il resto del tuo stack di server può manipolare. Ad esempio, se stai usando PHP per interagire con il tuo database, è molto probabile che il tentativo di gestire le date storiche prima o poi vada in crash (su un ambiente a 32 bit, l'intervallo per i timestamp in stile UNIX va dal 13 dicembre 1901 al 19 gennaio 2038).
In sintesi:MySQL memorizzerà correttamente qualsiasi data con un anno a 4 cifre; ma in generale l'utilizzo di timestamp per le date storiche è quasi garantito per innescare problemi e mal di testa il più delle volte. Sconsiglio vivamente tale utilizzo.
Spero che questo aiuti.
Modifica/aggiunta:
Non penso che nessun DB abbia troppo supporto per questo tipo di date:le applicazioni che lo utilizzano il più delle volte ne hanno abbastanza con la rappresentazione di stringhe/testo. In realtà, per le date dell'anno 1 e successive, una rappresentazione testuale produrrà anche un corretto ordinamento / confronto (purché la data sia rappresentata dall'ordine di grandezza:y,m,d order). I confronti si interromperanno, tuttavia, se sono coinvolte anche date "negative" (si confronteranno comunque come prima di qualsiasi data positiva, ma il confronto di due date negative produrrebbe un risultato inverso).
Se hai bisogno solo dell'anno 1 e delle date successive, o se non hai bisogno di un ordinamento, puoi semplificarti la vita usando le stringhe.
In caso contrario, l'approccio migliore è utilizzare una sorta di numero e definire il proprio "intervallo di tick" e "punto epocale". Un buon intervallo potrebbe essere giorni (a meno che tu non abbia davvero bisogno di ulteriore precisione, ma anche in questo caso puoi fare affidamento su numeri "reali" (virgola mobile) anziché su numeri interi); e un'epoca ragionevole potrebbe essere il 1 gennaio. Il problema principale sarà trasformare questi valori nella loro rappresentazione testuale, e viceversa. Devi tenere a mente i seguenti dettagli:
- Gli anni bisestili hanno un giorno in più.
- La regola per gli anni bisestili era "qualsiasi multiplo di 4" fino al 1582, quando passò dal calendario giuliano a quello gregoriano e divenne "multiplo di 4 eccetto quelli che sono multipli di 100 a meno che non siano anche multipli di 400".
- L'ultimo giorno del calendario giuliano era il 4 ottobre 1582. Il giorno successivo, il primo del calendario gregoriano, era il 15 ottobre 1582. Sono stati saltati 10 giorni per far coincidere nuovamente il nuovo calendario con le stagioni.
- Come affermato nei commenti, le due regole di cui sopra variano in base al paese:lo stato pontificio e alcuni paesi cattolici hanno adottato il nuovo calendario nelle date indicate, ma molti altri paesi hanno impiegato più tempo per farlo (l'ultimo è stato la Turchia nel 1926) . Ciò significa che qualsiasi data tra la bolla papale del 1582 e l'ultima adozione nel 1926 sarà ambigua senza contesto geografico e ancora più complessa da elaborare.
- Non esiste un "anno 0":l'anno prima dell'anno 1 era l'anno -1 o l'anno 1 aC.
Tutto ciò richiede funzioni di parser e formattatore piuttosto elaborate, ma al di là delle molte rotture caso per caso non c'è davvero troppa complessità (sarebbe noioso codificare, ma abbastanza semplice). L'uso dei numeri come rappresentazione sottostante garantisce un ordinamento/confronto corretto per qualsiasi coppia di valori.
Sapendo questo, ora sta a te scegliere l'approccio che meglio si adatta alle tue esigenze.
