Какое значение имеет 01.01.1753 в SQL Server?

Question

Почему 1753?Что они имеют против 1752 года?Мой пра-пра-пра-пра-пра-прадед был бы очень обижен.

Answer 1

Решение использовать 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)

Возвращает

Sep  8 1752 12:00AM

И последнее замечание, касающееся типа данных datetime2, заключается в том, что он использует пролептический григорианский календарь , спроецированный задолго до того, как он был изобретен, поэтому имеет ограниченное применение при работе с историческими датами.

Это отличается от других реализаций Программного обеспечения, таких как класс Java григорианского календаря , который по умолчанию следует юлианскому календарю для дат до 4 октября 1582 г., а затем переходит к 15 октября 1582 г. в новом григорианском календаре. Он правильно обрабатывает юлианскую модель високосного года до этой даты и григорианскую модель после этой даты. Дата переключения может быть изменена вызывающим абонентом путем вызова setGregorianChange().

Довольно интересную статью, в которой обсуждаются некоторые другие особенности с принятием календаря , можно найти здесь .

Answer 2

Ваш пра-пра-пра-пра-прадед должен обновить до SQL Server 2008 и использовать тип данных DateTime2 , который поддерживает даты в диапазоне: от 0001-01-01 до 9999-12-31.

Answer 3

1752 был годом перехода Британии с юлианского на григорианский календарь.Я полагаю, что две недели в сентябре 1752 года никогда не происходили, что имеет значение для дат в этой общей области.

Объяснение: http://uneasysilence.com/archive/2007/08/12008/ ( Версия интернет-архива )

Answer 4

Это целая история о том, как возникла проблема с датами и как большие СУБД справились с этими проблемами.

В период между 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 представляет собой гибридный календарь.)

Источник 1 и 2

Answer 5

Кстати, Windows больше не знает, как правильно конвертировать UTC в местное время США для определенных дат в марте / апреле или октябре / ноябре прошлых лет. Временные метки на основе UTC от этих дат теперь несколько бессмысленны. Было бы очень странно, если бы ОС просто отказывалась обрабатывать любые метки времени до последнего набора правил DST правительства США, поэтому некоторые из них просто обрабатываются неправильно. SQL Server отказывается обрабатывать даты до 1753 года, потому что для их правильной обработки потребуется много дополнительной специальной логики, и он не хочет обрабатывать их неправильно.