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

Question

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

Answer 1

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

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

Филипп Stanhope, 4-й граф Честерфилд. Кто руководил Calendar (New Style) Act 1750 через британский парламент. Это законодательно закреплено за принятие григорианского календаря для Британии и ее тогдашних колоний.

В британском календаре в 1752 году было missing days, когда настройка была сделана, наконец, из юлианского календаря. 3 сентября 1752 года по 13 сентября 1752 года были потеряны.

Kalen Делани explained выбор этот путь

Так, с 12 дней потерял, как вы можете даты Compute? Например, как можно определить 12 октября 1492 года и 4 июля 1776 года? Do вы включили те недостающие 12 дней? Чтобы избежать того, чтобы решить эту проблему, исходных сервер разработчики Sybase SQL решили не позволить датам , прежде чем 1753. Вы можете сохранить ранее даты с помощью символьных полей, но вы не можете использовать какую-либо функцию DATETIME с более ранние даты, которые вы храните в полях символов.

Выбор 1753 кажется несколько anglocentric, однако, как many catholic countries в Европе использовали календарь на 170 лет до британской реализации (первоначально отсрочено из-за оппозицию by the church). Напротив, многие страны не реформировали свои календари гораздо позже, в 1918 году в России. Действительно, Октябрьская революция 1917 года началась 7 ноября под григорианским календарем.

Оба datetime и новый тип данных datetime2 упоминается в Joe's answer не пытаются объяснить эти местные различия и просто используют григорианский календарь.

Так с большим диапазоном datetime2

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

Возвращения

Sep 8 1752 12:00AM 

Одна конечная точка с типом datetime2 данных является то, что он использует proleptic Gregorian calendar проецируется назад, чтобы задолго до того, он был на самом деле изобрел так имеет ограниченное применение при рассмотрении исторических дат.

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

Довольно интересная статья, посвященная обсуждению некоторых особенностей с принятием календаря can be found here.

Answer 2

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

Объяснение: http://uneasysilence.com/archive/2007/08/12008/ (Internet Archive version)

Answer 3

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

Answer 4

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

Answer 5

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

В период между 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. Пользователь Oracle найдет, что арифметическое выражение даты 15 октября 1582 минус октябрь 4 1582 дает значение 1 день (поскольку 5-14 октября не существует) и , что дата 29 февраля 1300 года действительна (поскольку Применимо правило Julian leap-year ). Почему Oracle пошел на дополнительные проблемы, когда SQL Standard, похоже, не требует этого? Ответ заключается в том, что пользователи могут использовать . Историки и астрономы используют эту гибридную систему вместо пролептивного григорианского календаря. (Это также вариант по умолчанию, что ВС выбрал при реализации класса GregorianCalendar для Java-несмотря на название, GregorianCalendar представляет собой гибрид календарь.)

Источник 1 и 2