MySQL поддерживает историческую дату (как 1200)?

Для конкретного примера, который вы использовали в своем вопросе (1200 год), технически все будет работать.

В целом, однако, использование временных меток для этого не рекомендуется. Во-первых, ограничение диапазона произвольно: в MySQL это 1 января 1000 года. Если вы работаете с материалами 12-13 веков, все идет хорошо. ... но если в какой-то момент вам нужно добавить что-то более старое (10-го века или ранее), дата с треском сломается, и для устранения проблемы потребуется переформатировать все ваши исторические даты во что-то более адекватное.

Временные метки обычно представлены в виде необработанных целых чисел с заданным «интервалом тактов» и «точкой эпохи», поэтому число действительно является количеством тактов, прошедших с эпохи до представленной даты (или наоборот для отрицательных дат). Это означает, что, как и с любым фиксированным целочисленным типом данных, набор представимых значений конечен. Большинство известных мне форматов временных меток жертвуют диапазоном в пользу точности, в основном потому, что приложениям, которым необходимо выполнять арифметику времени, часто требуется делать это с приличной точностью; в то время как приложениям, которым необходимо работать с историческими датами, очень редко требуется серьезная арифметика.

Другими словами, временные метки предназначены для точного представления дат.Секундная (или даже доля секунды) точность не имеет смысла для исторических дат: не могли бы вы сказать мне, с точностью до миллисекунд, когда Генрих VIII был коронован как король Англии?

В случае MySQL формат по сути является неизменным. определяется как "4-значные годы", поэтому любая связанная с этим оптимизация может основываться на предположении, что год будет состоять из 4-х цифр или что вся строка будет состоять ровно из 10 символов ("гггг-мм-дд") и т. д. Это просто удача, что дата, которую вы упомянули в заголовке, все еще подходит, но даже полагаться на нее по-прежнему опасно: помимо того, что может хранить сама БД, вам нужно знать, чем может манипулировать остальная часть вашего серверного стека. Например, если вы используете PHP для взаимодействия с базой данных, попытка обработки исторических дат в какой-то момент может привести к сбою (в 32-битной среде диапазон временных меток в стиле UNIX составляет от 13 декабря 1901 г. до 19 января 2038 г.).

В итоге: MySQL будет правильно хранить любую дату с 4-значным годом; но в целом использование временных меток для исторических дат почти всегда вызывает проблемы и головную боль. Я настоятельно не рекомендую такое использование.

Надеюсь, это поможет.

Правка / дополнение:

Спасибо за очень интересный ответ. Должен ли я создать свой собственный алгоритм для исторической даты или выбрать другой БД, но какой? - user284523

Я не думаю, что какая-либо БД слишком сильно поддерживает такие даты: приложения, использующие ее, чаще всего имеют достаточно строковое / текстовое представление.Фактически, для дат в год 1 и позже текстовое представление даже даст правильную сортировку / сравнение (если дата представлена ​​по порядку величины: y, m, d порядок). Однако сравнения не будут работать, если будут задействованы и «отрицательные» даты (они все равно будут сравниваться как более ранние, чем любые положительные, но сравнение двух отрицательных дат приведет к обратному результату).

Если вам нужны только даты 1-го года и более поздние, или если вам не нужна сортировка, вы можете значительно упростить себе жизнь, используя строки.

В противном случае, лучший подход - использовать какое-то число и определить свой собственный «интервал тика» и «точку эпохи». Хорошим интервалом могут быть дни (если вам действительно не нужна дополнительная точность, но даже тогда вы можете полагаться на «реальные» (с плавающей запятой) числа вместо целых); и подходящей эпохой может быть 1 января. Основная проблема будет заключаться в преобразовании этих значений в их текстовое представление и наоборот. Вам нужно иметь в виду следующие детали:

• В високосных годах есть один дополнительный день.
• Правило для високосных лет было «любое кратное 4» до 1582 года, когда оно изменилось с юлианского на григорианский календарь и стало «кратным 4, за исключением тех, которые кратны 100, если они также не кратны 400».
• Последним днем ​​по юлианскому календарю было 4 октября 1582 года. Следующим днем, первым по григорианскому календарю, было 15 октября 1582 года. 10 дней были пропущены, чтобы новый календарь снова соответствовал временам года.
• Как указано в комментариях, два приведенных выше правила различаются в зависимости от страны: Папские государства и некоторые католические страны действительно приняли новый календарь в указанные даты, но во многих других странах для этого потребовалось больше времени (последней из них была Турция в 1926 году) . Это означает, что любая дата между папской буллой в 1582 году и последним принятием в 1926 году будет неоднозначной без географического контекста и даже более сложной для обработки.
• Не существует "года 0":год до 1 года был годом -1 или 1 годом до н. э.

Для всего этого требуются довольно сложные функции синтаксического анализатора и форматирования, но, помимо множества разбиений в каждом конкретном случае, на самом деле не так уж много сложностей (было бы утомительно кодировать, но довольно просто). Использование чисел в качестве базового представления обеспечивает правильную сортировку / сравнение для любой пары значений.

Зная это, теперь вы можете выбрать подход, который лучше соответствует вашим потребностям.