Какое значение имеет 01.01.1753 в SQL Server?
Это зависит от вашего компилятора. Вам гарантировано, что длинный будет по крайней мере таким же большим, как int, но вы не гарантируете, что он будет больше.
4 ответа
Решение использовать 1 января 1753 года (1753-01-01) в качестве минимального значения даты в SQL Server восходит к истокам Sybase.
Однако значение самой даты можно приписать этому человеку.
Филип Стэнхоуп, 4-й граф Честерфилд. Он провел через британский парламент Акт о календаре (новый стиль) 1750 года. Этот закон предусматривал принятие григорианского календаря для Великобритании и ее тогдашних колоний.
В 1752 году в британском календаре было несколько пропущенных дней, когда была произведена окончательная корректировка юлианского календаря. Были потеряны дни с 3 сентября 1752 года по 13 сентября 1752 года.
Кален Дилейни объяснил этот выбор так
Итак, с 12 потерянными днями, как вы можете вычислять даты? Например, как можно вычислить количество дней между 12 октября 1492 года и 4 июля 1776 года? Нужно ли вы включите недостающие 12 дней? Чтобы избежать решения этой проблемы, первоначальные разработчики Sybase SQL Server разработчики решили не допускать даты до 1753 года. Вы можете хранить более ранние даты, используя символьные поля, но вы не можете использовать какие-либо функции времени даты с более ранними датами, которые вы храните в символьных полях.
Однако выбор 1753 года кажется несколько англоцентричным, поскольку многие католические страны в Европе использовали календарь в течение 170 лет до введения британского календаря (первоначально отложенного из-за противодействия церкви). И наоборот, многие страны не реформировали свои календари до гораздо более позднего времени, 1918 года в России. Действительно, Октябрьская революция 1917 года началась 7 ноября по григорианскому календарю.
И datetime, и новый тип данных datetime2, упомянутый в ответе Джо, не пытаются учесть эти местные различия и просто используют григорианский календарь.
Таким образом, с большим диапазоном datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
Returns
Sep 8 1752 12:00AM
Последнее замечание по поводу типа данных datetime2 заключается в том, что он использует пролептический григорианский календарь, спроецированный назад задолго до того, как он был на самом деле изобретен, поэтому он ограничен в использовании для работы с историческими датами.
Это контрастирует с другими программными реализациями, такими как класс Java Gregorian Calendar, который по умолчанию следует юлианскому календарю для дат до 4 октября 1582 года, а затем переходит на 15 октября 1582 года по новому григорианскому календарю. Он правильно обрабатывает юлианскую модель високосного года до этой даты и григорианскую модель после этой даты. Дата перехода может быть изменена вызывающей стороной путем вызова setGregorianChange().
Довольно занимательную статью, в которой обсуждаются еще некоторые особенности принятия календаря можно найти здесь.
Ваш пра-пра-пра-пра-прадед должен обновить до SQL Server 2008 и использовать тип данных DateTime2 , который поддерживает даты в диапазоне: от 0001-01-01 до 9999-12-31.
1752 год был годом перехода Британии с юлианского на григорианский календарь. Я полагаю, что две недели в сентябре 1752 года никогда не происходили в результате, что имеет значение для дат в этой общей области.
Объяснение: http://uneasysilence.com/archive/2007/08/12008/ ( Версия интернет-архива )
Кстати, Windows больше не знает, как правильно преобразовать UTC в местное время США для определенных дат в марте / апреле или октябре / ноябре прошлых лет. Отметки времени на основе UTC от этих дат теперь несколько бессмысленны. Было бы очень неприятно, если бы ОС просто отказалась обрабатывать любые временные метки, предшествующие последнему набору правил DST правительства США, поэтому она просто неправильно обрабатывает некоторые из них. SQL Server отказывается обрабатывать даты до 1753 года, потому что для их правильной обработки потребовалось бы много дополнительной специальной логики, и он не хочет обрабатывать их неправильно.