Каково значение 1/1/1753 в SQL Server?

Ответ 1

Решение использовать 1 января 1753 года (1753-01-01) в качестве минимального значения даты для даты в SQL Server возвращается к Sybase originins.

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

Филипп Стэнхоуп, 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, упомянутый в Joe answer, не пытаются учитывать эти локальные различия и просто используют григорианский календарь.

Итак, с большим диапазоном datetime2

SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)

Возвращает

Sep  8 1752 12:00AM

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

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

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

Ответ 2

Ваш великий великий великий великий великий прадед должен перейти на SQL Server 2008 и использовать

Ответ 3

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

Ответ 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

Ответ 5

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