Pro konkrétní příklad, který jste použili ve své otázce (rok 1200), budou věci technicky fungovat.
Obecně se však časová razítka pro toto použití nedoporučují. Za prvé, omezení rozsahu je libovolné:v MySQL je to 1. ledna 1000. Pokud pracujete s věcmi z 12. až 13. století, věci jdou dobře... musíte přidat něco staršího (10. století nebo dříve), datum se nešťastně pokazí a oprava problému bude vyžadovat přeformátování všech vašich historických dat na něco adekvátnějšího.
Časová razítka jsou normálně reprezentována jako nezpracovaná celá čísla s daným „intervalem tikání“ a „bodem epochy“, takže číslo je ve skutečnosti počet tiků, které uplynuly od epochy do reprezentovaného data (nebo naopak pro záporná data). To znamená, že stejně jako u jakéhokoli datového typu s pevným celočíselným číslem je množina reprezentovatelných hodnot konečná. Většina formátů časových razítek, které znám, obětuje rozsah ve prospěch přesnosti, většinou proto, že aplikace, které potřebují provádět aritmetiku času, to často potřebují dělat se slušnou přesností; zatímco aplikace, které potřebují pracovat s historickými daty, potřebují velmi zřídka provádět seriózní aritmetiku.
Jinými slovy, časová razítka jsou určena pro přesnost reprezentace dat. Druhá (nebo dokonce zlomek sekundy) přesnost nedává pro historická data smysl:mohl byste mi s přesností na milisekundy říct, kdy byl Jindřich 8. korunován anglickým králem?
V případě MySQL je formát ze své podstaty definován jako „4místné roky“, takže jakákoli související optimalizace se může spoléhat na předpoklad, že rok bude mít 4 číslice nebo že celý řetězec bude mít přesně 10 znaků („yyyy- mm-dd") atd. Je jen otázkou štěstí, že datum, které jste uvedl ve svém názvu, stále sedí, ale i spoléhat se na to je stále nebezpečné:kromě toho, co může uložit samotná DB, musíte vědět, co zbytek vašeho zásobníku serveru může manipulovat. Pokud například používáte PHP k interakci s databází, pokusy o zpracování historických dat velmi pravděpodobně v určitém okamžiku selžou (v 32bitovém prostředí je rozsah časových razítek ve stylu UNIX od 13. prosince 1901 do 19. ledna 2038).
Stručně řečeno:MySQL správně uloží jakékoli datum se 4místným rokem; ale obecně použití časových razítek pro historická data téměř zaručeně způsobí problémy a bolesti hlavy častěji než ne. Důrazně nedoporučuji takové použití.
Doufám, že to pomůže.
Úprava/doplnění:
Nemyslím si, že žádná DB má příliš velkou podporu pro tento druh dat:aplikace, které ji používají, si nejčastěji vystačí s řetězcovou/textovou reprezentací. Ve skutečnosti, pro data v roce 1 a později, textová reprezentace dokonce poskytne správné řazení / srovnání (pokud je datum reprezentováno řádově:y,m,d pořadí). Srovnání se však přeruší, pokud jsou zahrnuta i „záporná“ data (stále by se porovnávala jako dřívější než kterákoli kladná, ale porovnání dvou záporných dat by přineslo opačný výsledek).
Pokud potřebujete pouze data z roku 1 a pozdější, nebo pokud nepotřebujete třídění, můžete si život výrazně zjednodušit pomocí řetězců.
V opačném případě je nejlepším přístupem použít nějaký druh čísla a definovat svůj vlastní „interval tikání“ a „bod epochy“. Dobrým intervalem mohou být dny (pokud opravdu nepotřebujete další upřesnění, ale i tehdy se můžete spolehnout na „skutečná“ čísla (s plovoucí desetinnou čárkou) namísto celých čísel); a rozumnou epochou by mohl být 1. leden. Hlavním problémem bude převést tyto hodnoty na jejich textovou reprezentaci a naopak. Musíte mít na paměti následující podrobnosti:
- Přestupné roky mají jeden den navíc.
- Pravidlo pro přestupné roky bylo „jakýkoli násobek 4“ až do roku 1582, kdy se změnilo z juliánského na gregoriánský kalendář a stalo se „násobkem 4 kromě těch, které jsou násobky 100, pokud nejsou také násobky 400“.
- Posledním dnem juliánského kalendáře byl 4. říjen 1582. Další den, první den gregoriánského kalendáře, byl 15. říjen 1582. Bylo vynecháno 10 dní, aby nový kalendář znovu odpovídal ročním obdobím.
- Jak je uvedeno v komentářích, dvě výše uvedená pravidla se v jednotlivých zemích liší:Papežské státy a některé katolické země přijaly nový kalendář v uvedených datech, ale mnoha dalším zemím to trvalo déle (posledním bylo Turecko v roce 1926). . To znamená, že jakékoli datum mezi papežskou bulou v roce 1582 a posledním přijetím v roce 1926 bude bez geografického kontextu nejednoznačné a ještě složitější na zpracování.
- Neexistuje žádný „rok 0“:rok před rokem 1 byl rok -1 nebo rok 1 před naším letopočtem.
To vše vyžaduje poměrně propracované funkce analyzátoru a formátovače, ale kromě mnoha případ od případu lámání není ve skutečnosti příliš složitá (bylo by únavné kódovat, ale docela přímočaré). Použití čísel jako základní reprezentace zajišťuje správné řazení/porovnávání pro jakýkoli pár hodnot.
Když to víte, je nyní na vás, abyste zvolili přístup, který lépe vyhovuje vašim potřebám.