За конкретния пример, който сте използвали във вашия въпрос (година 1200), технически нещата ще работят.
Като цяло обаче времевите марки не са препоръчителни за тази употреба. Първо, ограничението на диапазона е произволно:в MySQL това е 1 януари 1000. Ако работите с неща от 12-13 век, нещата вървят добре... но ако в даден момент трябва да добавите нещо по-старо (10-ти век или по-рано), датата ще се счупи мизерно и отстраняването на проблема ще изисква повторно форматиране на всичките ви исторически дати в нещо по-адекватно.
Времевите марки обикновено се представят като необработени цели числа, с даден „интервал на отметка“ и „епоха“, така че числото наистина е броят на тиковете, изминали от епохата до представената дата (или обратно за отрицателни дати). Това означава, че както при всеки тип данни с фиксирано число, наборът от представими стойности е краен. Повечето формати на времеви отпечатъци, които познавам за обхвата на жертва в полза на прецизността, най-вече защото приложенията, които трябва да извършват аритметика на времето, често трябва да го правят с прилична прецизност; докато приложенията, които трябва да работят с исторически дати, много рядко трябва да извършват сериозна аритметика.
С други думи, времевите марки са предназначени за прецизно представяне на дати. Втората (или дори част от секундата) точност няма смисъл за исторически дати:бихте ли ми казали с точност до милисекунди кога Хенри 8-ми е коронясан като крал на Англия?
В случая на MySQL форматът е присъщо дефиниран като "4-цифрени години", така че всяка свързана оптимизация може да разчита на предположението, че годината ще има 4 цифри или че целият низ ще има точно 10 символа ("yyyy- mm-dd") и т.н. Въпрос на късмет е, че датата, която споменахте в заглавието си, все още пасва, но дори да разчитате на това все още е опасно:освен това, което самата DB може да съхранява, трябва да сте наясно какво останалата част от вашия сървърен стек може да манипулира. Например, ако използвате PHP за взаимодействие с вашата база данни, опитът за обработка на исторически дати е много вероятно да се срине в даден или друг момент (в 32-битова среда диапазонът за времеви печати в стил UNIX е от 13 декември 1901 г. до 19 януари 2038 г.).
В обобщение:MySQL ще съхранява правилно всяка дата с 4-цифрена година; но като цяло използването на времеви печати за исторически дати е почти гарантирано, че ще предизвика проблеми и главоболия по-често, отколкото не. Силно не препоръчвам такава употреба.
Надявам се това да помогне.
Редактиране/добавяне:
Не мисля, че никоя DB има твърде много поддръжка за този вид дати:приложенията, които го използват, най-често имат достатъчно с низово/текстово представяне. Всъщност, за дати от година 1 и по-късно, текстовото представяне дори ще даде правилно сортиране / сравнения (стига датата е представена по порядък на величина:y,m,d ред). Сравненията обаче ще прекъснат, ако са включени и „отрицателни“ дати (те все пак ще се сравняват по-рано от всяка положителна, но сравняването на две отрицателни дати би довело до обратен резултат).
Ако имате нужда само от година 1 и по-късни дати или ако не се нуждаете от сортиране, тогава можете да улесните живота си много, като използвате низове.
В противен случай най-добрият подход е да използвате някакъв вид число и да дефинирате свой собствен "интервал на отметка" и "епоха". Добър интервал може да бъде дни (освен ако наистина не се нуждаете от допълнителна прецизност, но дори и тогава можете да разчитате на "реални" (с плаваща запетая) числа вместо цели числа); и разумна епоха може да бъде 1, 1 януари. Основният проблем ще бъде превръщането на тези стойности в тяхното текстово представяне и обратно. Трябва да имате предвид следните подробности:
- Високосните години имат един допълнителен ден.
- Правилото за високосните години беше „всяко кратно на 4“ до 1582 г., когато се промени от юлианския на григорианския календар и стана „кратно на 4, освен тези, които са кратни на 100, освен ако не са кратни и на 400“.
- Последният ден от юлианския календар беше 4 октомври 1582 г. Следващият ден, първият от григорианския календар, беше 15 октомври 1582 г. Бяха пропуснати 10 дни, за да може новият календар да съвпадне отново със сезоните.
- Както е посочено в коментарите, двете правила по-горе се различават в зависимост от държавата:папските държави и някои католически държави наистина приеха новия календар на посочените дати, но на много други държави им отне повече време (последната беше Турция през 1926 г.) . Това означава, че всяка дата между папската була през 1582 г. и последното осиновяване през 1926 г. ще бъде двусмислена без географски контекст и дори по-сложна за обработка.
- Няма „година 0“:годината преди година 1 беше година -1 или година 1 пр.н.е.
Всичко това изисква доста сложни функции за анализатор и форматиране, но отвъд многото счупвания за всеки отделен случай всъщност няма твърде много сложност (би било досадно да се кодира, но доста просто). Използването на числа като основно представяне гарантира правилно сортиране/сравняване за всяка двойка стойности.
Знаейки това, сега е ваш избор да използвате подхода, който по-добре отговаря на вашите нужди.
