Яке значення 1/1/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 року. Можна зберігати більш ранні дати за допомогою полів символів, але ви не можете використовувати жодні функції дат із більш ранніми датами, які ви зберігаєте в символі поля.
Вибір 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. Користувач Oracle знайде, що арифметичний вираз дати 15 жовтня 1582 р. Мінус 4 жовтня 1582 р. Дає значення 1 день (оскільки 5–14 жовтня не існує), а дата 29 лютого 1300 р. Є дійсною (оскільки перехід Юліана - застосовується правило року). Чому Oracle пішов на додаткові проблеми, коли стандарт SQL, схоже, цього не вимагає? Відповідь полягає в тому, що користувачі можуть цього вимагати. Історики та астрономи використовують цю гібридну систему замість пролептичного григоріанського календаря. (Це також варіант за замовчуванням, який Sun вибрав під час впровадження класу GregorianCalendar для Java - незважаючи на ім'я, GregorianCalendar - це гібридний календар.)
Між іншим, Windows більше не знає, як правильно перетворити UTC на місцевий час США для певних дат у березні / квітні чи жовтні / листопаді минулих років. Часові позначки, засновані на UTC, від цих дат зараз дещо безглузді. Було б дуже приємно для ОС просто відмовитися від обробки будь-яких часових позначок до останнього набору правил уряду США, тому вона просто обробляє деякі з них неправильно. SQL Server відмовляється обробляти дати до 1753 р., Оскільки для правильного поводження з ними потрібно буде багато додаткової спеціальної логіки, і він не хоче керувати ними неправильно.