Какое значение имеет 01.01.1753 в SQL Server?
Ответы:
Решение использовать 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 года. Вы можете хранить более ранние даты, используя символьные поля, но вы не можете использовать функции datetime с более ранними датами, которые вы храните в символьных поля.
Однако выбор 1753 года кажется несколько англоцентричным, поскольку многие католические страны в Европе использовали календарь за 170 лет до британской реализации (первоначально отсроченной из-за противодействия со стороны церкви ). И наоборот, многие страны не реформировали свои календари намного позже 1918 года в России. Действительно, Октябрьская революция 1917 года началась 7 ноября по григорианскому календарю.
Оба, datetimeи новый datetime2тип данных, упомянутый в ответе Джо, не пытаются объяснить эти локальные различия и просто используют григорианский календарь.
Так что с большим диапазоном datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)Возвращает
Sep 8 1752 12:00AMИ последнее замечание, касающееся datetime2типа данных, заключается в том, что в нем используется пролонгированный григорианский календарь, спроецированный назад задолго до того, как он был изобретен, поэтому он имеет ограниченное применение при работе с историческими датами.
Это отличается от других реализаций Программного обеспечения, таких как класс Java григорианского календаря, который по умолчанию следует за юлианским календарем для дат до 4 октября 1582 года, а затем переходит к 15 октября 1582 года в новом григорианском календаре. Он правильно обрабатывает юлианскую модель високосного года до этой даты и григорианскую модель после этой даты. Дата переключения может быть изменена звонящим по телефону setGregorianChange().
Довольно увлекательная статья, в которой обсуждаются некоторые особенности с принятием календаря, можно найти здесь .
Ваш пра-пра-пра-пра-пра-дедушка должен перейти на SQL Server 2008 и использовать тип данных DateTime2 , который поддерживает даты в диапазоне от 0001-01-01 до 9999-12-31.
1752 год был годом перехода Британии с юлианского на григорианский календарь. Я полагаю, что две недели в сентябре 1752 года никогда не были результатом, что имеет значение для дат в этой общей области.
Объяснение: http://uneasysilence.com/archive/2007/08/12008/ ( версия интернет-архива )
Это целая история о том, как возникла проблема с датами и как большие СУБД справились с этими проблемами.
В период между 1 г. н.э. и сегодня в западном мире фактически использовались два основных календаря: юлианский календарь Юлия Цезаря и григорианский календарь папы Григория XIII. Два календаря отличаются только одним правилом: правилом определения високосного года. В юлианском календаре все годы, делимые на четыре, являются високосными. В григорианском календаре все годы, кратные четырем, являются високосными, за исключением того, что годы, кратные 100 (но не делимые на 400), не являются високосными. Таким образом, 1700, 1800 и 1900 годы являются високосными годами в юлианском календаре, но не в григорианском календаре, в то время как 1600 и 2000 годы являются високосными годами в обоих календарях.
Когда папа Григорий XIII представил свой календарь в 1582 году, он также дал указание пропустить дни с 4 октября 1582 года по 15 октября 1582 года, то есть сказал, что днем после 4 октября должен быть 15 октября. Многие страны отложенное переключение, хотя. Англия и ее колонии не переходили с юлианского на григорианский расчет до 1752 года, поэтому для них пропущенные даты были между 4 сентября и 14 сентября 1752 года. Другие страны переключались в другое время, но 1582 и 1752 годы являются соответствующими датами для СУБД, которые мы обсуждаем.
Таким образом, две проблемы возникают с арифметикой даты, когда человек возвращается на много лет назад. Во-первых, должны ли високосные годы, прежде чем переход рассчитываться в соответствии с юлианскими или григорианскими правилами? Вторая проблема заключается в том, когда и как следует обрабатывать пропущенные дни?
Вот как Большие СУБД справляются с этими вопросами:
- Притворись, что не было выключателя. Это то, чего требует стандарт SQL, хотя стандартный документ неясен: он просто говорит, что даты «ограничены естественными правилами для дат с использованием григорианского календаря» - какими бы ни были «естественные правила». Этот вариант выбрал DB2. Когда есть предлог, что правила единого календаря всегда применяются даже в те времена, когда никто не слышал о календаре, технический термин заключается в том, что действует «пролептический» календарь. Так, например, мы могли бы сказать, что DB2 следует грипсовому календарю.
- Избегайте проблемы полностью. Microsoft и Sybase установили свои минимальные значения даты на 1 января 1753 года, благополучно минуя время, когда Америка переключала календари. Это оправданно, но время от времени появляются жалобы на то, что этим двум СУБД не хватает полезной функциональности, которая есть у других СУБД и которая требуется в стандарте SQL.
- Пик 1582. Это то, что сделал Оракул. Пользователь Oracle обнаружит, что арифметическое выражение даты 15 октября 1582 года минус 4 октября 1582 года дает значение 1 день (потому что 5–14 октября не существует) и что дата 29 февраля 1300 года действительна (потому что юлианский скачок правило года применяется). Почему у Oracle возникли дополнительные проблемы, когда стандарт SQL, похоже, этого не требует? Ответ заключается в том, что пользователям может потребоваться это. Историки и астрономы используют эту гибридную систему вместо григорианского календаря. (Это также опция по умолчанию, которую Sun выбрал при реализации класса GregorianCalendar для Java - несмотря на название, GregorianCalendar - это гибридный календарь.)
Кстати, Windows больше не знает, как правильно конвертировать UTC в местное время США для определенных дат в марте / апреле или октябре / ноябре прошлых лет. Временные метки на основе UTC от этих дат теперь несколько бессмысленны. Было бы очень странно, если бы ОС просто отказывалась обрабатывать любые метки времени до последнего набора правил DST правительства США, поэтому некоторые из них просто обрабатываются неправильно. SQL Server отказывается обрабатывать даты до 1753 года, потому что для их правильной обработки потребуется много дополнительной специальной логики, и он не хочет обрабатывать их неправильно.