W przypadku konkretnego przykładu, którego użyłeś w swoim pytaniu (rok 1200), technicznie wszystko będzie działać.
Generalnie jednak znaczniki czasu są niewskazane do takich zastosowań. Po pierwsze, ograniczenie zakresu jest arbitralne:w MySQL jest to 1 stycznia 1000. Jeśli pracujesz z rzeczami z XII-XIII wieku, wszystko idzie dobrze... ale jeśli w pewnym momencie musisz dodać coś starszego (z 10. wieku lub wcześniej), data żałośnie się zepsuje, a naprawienie problemu będzie wymagało ponownego sformatowania wszystkich twoich historycznych dat na bardziej adekwatne.
Znaczniki czasu są zwykle przedstawiane jako nieprzetworzone liczby całkowite, z określonym „interwałem tiku” i „punktem epoki”, więc liczba jest rzeczywiście liczbą tików, które upłynęły od epoki do reprezentowanej daty (lub odwrotnie w przypadku dat ujemnych). Oznacza to, że podobnie jak w przypadku każdego typu danych typu fixed-with integer, zbiór reprezentowalnych wartości jest skończony. Większość formatów znaczników czasu, które znam, poświęca zakres na rzecz precyzji, głównie dlatego, że aplikacje, które muszą wykonywać arytmetykę czasu, często muszą to robić z przyzwoitą precyzją; podczas gdy aplikacje, które muszą pracować z datami historycznymi, bardzo rzadko muszą wykonywać poważne operacje arytmetyczne.
Innymi słowy, znaczniki czasu mają na celu dokładność reprezentacja dat. Druga (lub nawet ułamek sekundy) precyzja nie ma sensu w przypadku dat historycznych:czy możesz mi powiedzieć, z dokładnością do milisekund, kiedy Henryk VIII został koronowany na króla Anglii?
W przypadku MySQL format jest z natury zdefiniowany jako „lata 4-cyfrowe”, więc każda powiązana optymalizacja może polegać na założeniu, że rok będzie miał 4 cyfry lub że cały ciąg będzie miał dokładnie 10 znaków („yyyy- mm-dd”) itp. To tylko kwestia szczęścia, że data podana w tytule nadal pasuje, ale nawet poleganie na niej jest nadal niebezpieczne:poza tym, co może przechowywać sam DB, musisz być świadomy tego, co reszta stosu serwera może manipulować. Na przykład, jeśli używasz PHP do interakcji z bazą danych, próba obsługi dat historycznych najprawdopodobniej ulegnie awarii w pewnym momencie (w środowisku 32-bitowym, zakres znaczników czasu w stylu UNIX wynosi od 13 grudnia 1901 do 19 stycznia 2038).
Podsumowując:MySQL będzie prawidłowo przechowywać każdą datę z 4-cyfrowym rokiem; ale ogólnie używanie znaczników czasu dla dat historycznych prawie na pewno spowoduje problemy i bóle głowy częściej niż nie. Zdecydowanie odradzam takie użycie.
Mam nadzieję, że to pomoże.
Edycja/dodawanie:
Nie sądzę, aby jakakolwiek baza danych miała zbyt duże wsparcie dla tego rodzaju dat:aplikacje używające go najczęściej mają wystarczającą reprezentację ciągu/tekstu. W rzeczywistości, w przypadku dat w roku 1 i późniejszych, reprezentacja tekstowa zapewni nawet prawidłowe sortowanie/porównania (o ile data jest reprezentowana przez rząd wielkości:rząd r, m, d). Jednak porównania zostaną przerwane, jeśli w grę wchodzą również daty „ujemne” (nadal byłyby porównywane jako wcześniejsze niż jakiekolwiek pozytywne, ale porównanie dwóch dat ujemnych dałoby odwrotny wynik).
Jeśli potrzebujesz tylko dat z roku 1 i późniejszych lub jeśli nie potrzebujesz sortowania, możesz znacznie ułatwić sobie życie, używając ciągów.
W przeciwnym razie najlepszym podejściem jest użycie jakiejś liczby i zdefiniowanie własnego „interwału tiku” i „punktu epoki”. Dobrym przedziałem mogą być dni (chyba że naprawdę potrzebujesz większej precyzji, ale nawet wtedy możesz polegać na „rzeczywistych” (zmiennoprzecinkowych) liczbach zamiast liczb całkowitych); a rozsądną epoką może być 1 stycznia 1. Głównym problemem będzie skierowanie tych wartości na ich reprezentację tekstową i vice versa. Należy pamiętać o następujących szczegółach:
- Lata przestępna mają jeden dodatkowy dzień.
- Zasadą lat przestępnych była „dowolna wielokrotność 4” aż do 1582 roku, kiedy to zmienił się z kalendarza juliańskiego na kalendarz gregoriański i stał się „wielokrotnością 4 z wyjątkiem tych, które są wielokrotnościami 100, chyba że są również wielokrotnościami 400”.
- Ostatnim dniem kalendarza juliańskiego był 4 października 1582. Następny dzień, pierwszy w kalendarzu gregoriańskim, to 15 października 1582. Pominięto 10 dni, aby nowy kalendarz ponownie pasował do pór roku.
- Jak stwierdzono w komentarzach, dwie powyższe zasady różnią się w zależności od kraju:państwa papieskie i niektóre kraje katolickie przyjęły nowy kalendarz w określonych dniach, ale wiele innych krajów zajęło to dłużej (ostatnią z nich była Turcja w 1926 r.) . Oznacza to, że każda data między bullą papieską w 1582 a ostatnią adopcją w 1926 będzie niejednoznaczna bez kontekstu geograficznego, a jeszcze bardziej skomplikowana do przetworzenia.
- Nie ma „roku 0”:rok przed rokiem 1 był rokiem -1, czyli rokiem 1 pne.
Wszystko to wymaga dość rozbudowanych funkcji parsera i formatera, ale poza licznymi łamaniami poszczególnych przypadków nie ma zbyt dużej złożoności (kodowanie byłoby nużące, ale całkiem proste). Użycie liczb jako podstawowej reprezentacji zapewnia prawidłowe sortowanie/porównywanie dla dowolnej pary wartości.
Wiedząc o tym, teraz możesz wybrać podejście, które lepiej odpowiada Twoim potrzebom.
