SQL Server에서 17/1753의 의미는 무엇입니까?
답변:
1753 년 1 월 1 일 1753-01-01SQL Server에서 datetime의 최소 날짜 값 으로 사용하기로 한 결정 은 Sybase 오리진 으로 돌아갑니다 .
날짜 자체의 중요성은이 사람에 기인 할 수 있습니다.
체스터 필드 제 4 백작 필립 스탠 호프. 영국 의회를 통해 1750 년 달력 (신식) 법을 조종 한 사람 . 이 법안은 영국과 그 당시 식민지에 대한 그레고리오 달력 채택에 대해 제정되었습니다.
일부 있었다 없는 일 (인터넷 아카이브 링크) 조정이 마침내 율리우스 력에서 만든 때 영국 달력은 1752 년. 1752 년 9 월 3 일부터 1752 년 9 월 13 일까지졌습니다.
Kalen Delaney 는 이러한 선택을 설명 했습니다
12 일을 잃어버린 날짜를 어떻게 계산할 수 있습니까? 예를 들어 1492 년 10 월 12 일과 1776 년 7 월 4 일 사이의 일 수를 어떻게 계산할 수 있습니까? 12 일이 지난 사람도 포함합니까? 이 문제를 해결하지 않으려면 원래 Sybase SQL Server 개발자는 1753 이전의 날짜를 허용하지 않기로 결정했습니다. 문자 필드를 사용하여 이전 날짜를 저장할 수는 있지만 문자에 저장 한 이전 날짜에는 날짜 시간 함수를 사용할 수 없습니다 필드.
1753 년의 선택은 유럽의 많은 가톨릭 국가들이 영국에서 시행되기 전 170 년 동안이 달력을 사용해 왔기 때문에 (당초 교회의 반대 때문에 지연되었다) 1753의 선택은 다소 엉망인 것처럼 보인다 . 반대로 많은 국가들이 1918 년 러시아에서 훨씬 더 늦게까지 달력을 개혁하지 않았다. 실제로 1917 년 10 월 혁명은 11 월 7 일 그레고리력으로 시작되었습니다.
모두 datetime새 datetime2에 언급 된 데이터 타입 조의 대답은 이 지역의 차이를 계정에 시도 할 단순히 태양력을 사용하지 마십시오.
따라서 더 넓은 범위의 datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)보고
Sep 8 1752 12:00AMdatetime2데이터 유형 의 한 가지 마지막 요점 은 실제로 발명되기 전에 거꾸로 투영 된 독창적 인 그레고리력을 사용 하므로 역사적인 날짜를 다루는 데 제한적으로 사용된다는 것입니다.
이것은 Java Gregorian Calendar 클래스 와 같은 다른 소프트웨어 구현과는 달리 기본적으로 1582 년 10 월 4 일까지 줄리안 달력을 따르고 새 Gregorian 달력에서 1582 년 10 월 15 일로 점프합니다. 해당 날짜 이전의 윤년 모델과 해당 날짜 이후의 그레고리 모델을 올바르게 처리합니다. 컷 오버 날짜는을 호출하여 호출자가 변경할 수 있습니다 setGregorianChange().
달력 채택과 함께 더 많은 특징을 논의하는 상당히 재미있는 기사 는 여기에서 찾을 수 있습니다 .
위대한 위대한 위대한 위대한 위대한 할아버지는 SQL Server 2008로 업그레이드하고 0001-01-01에서 9999-12-31 범위의 날짜를 지원 하는 DateTime2 데이터 형식을 사용해야합니다 .
1752 년은 영국이 줄리안에서 그레고리력으로 전환 한 해였습니다. 나는 1752 년 9 월의 2 주가 그 결과로 결코 일어나지 않았다고 생각하는데, 이는 그 일반 지역의 날짜에 영향을 미칩니다.
설명 : http://uneasysilence.com/archive/2007/08/12008/ ( 인터넷 아카이브 버전 )
이것은 날짜 문제의 방식과 Big DBMS가 이러한 문제를 어떻게 처리했는지에 대한 전체 이야기입니다.
서기 세계는 서기 1 년부터 오늘날까지 줄 리우스 카이사르의 율리우스 력 달력과 교황 그레고리 13 세의 그레고리력 달력을 사용했습니다. 두 달력은 단 하나의 규칙, 즉 윤년이 무엇인지 결정하는 규칙과 관련하여 다릅니다. 율리우스 력에서 4로 나눌 수있는 모든 연도는 윤년입니다. 그레고리력에서 4로 나눌 수있는 모든 연도는 윤년이며, 100으로 나눌 수있는 연도 (400으로 나눌 수는 없음)는 윤년이 아닙니다. 따라서 1700 년, 1800 년 및 1900 년은 율리우스 력 달력에서는 윤년이지만 그레고리력에서는 그렇지 않습니다. 1600 년과 2000 년은 두 달력에서 윤년입니다.
교황 그레고리 13 세가 1582 년에 자신의 달력을 발표했을 때 그는 1582 년 10 월 4 일과 1582 년 10 월 15 일 사이의 날을 건너 뛰어야한다고 지시했다. 그러나 전환이 지연되었습니다. 영국과 그녀의 식민지는 1752 년까지 줄리안에서 그레고리력으로 전환하지 않았으므로, 건너 뛴 날짜는 1752 년 9 월 4 일에서 9 월 14 일 사이였습니다. 다른 국가는 다른 시간대로 전환했지만 1582 년과 1752 년은 우리가 논의하고있는 DBMS.
따라서 몇 년 전으로 돌아 가면 날짜 산술에 두 가지 문제가 발생합니다. 첫 번째는 스위치가 Julian 또는 Gregorian 규칙에 따라 계산되기 몇 년 전에 도약해야합니까? 두 번째 문제는 건너 뛴 날짜를 언제 어떻게 처리해야합니까?
이것이 Big DBMS가 이러한 질문을 처리하는 방법입니다.
- 스위치가없는 척합니다. 표준 문서는 명확하지 않지만 SQL 표준에서 요구하는 것입니다. 날짜는 "그레고리력을 사용하는 날짜의 자연 규칙에 의해 제한됩니다"( "자연 규칙"). 이것이 DB2가 선택한 옵션입니다. 달력에 대해 들어 본 사람이없는 경우에도 단일 달력의 규칙이 항상 적용되었다고 주장하는 경우 기술 용어는 "폭발적인"달력이 적용되는 것입니다. 예를 들어, DB2가 그레고리력 달력을 따른다고 말할 수 있습니다.
- 문제를 완전히 피하십시오. Microsoft와 Sybase는 1753 년 1 월 1 일에 최소 날짜 값을 설정했습니다. 이는 방어가 가능하지만 때때로이 두 DBMS에는 다른 DBMS가 가지고 있고 SQL 표준에 필요한 유용한 기능이 없다는 불만이 제기됩니다.
- 1582를 선택하십시오. 이것이 오라클이 한 일입니다. Oracle 사용자는 1582 년 10 월 15 일에서 1582 년 10 월 4 일을 뺀 날짜 계산식이 10 월 5 일에서 14 일까지 존재하지 않기 때문에 1 일의 값을 산출하고 1300 년 2 월 29 일 날짜가 유효하다는 것을 알 수 있습니다. 연도 규칙이 적용됩니다). SQL 표준이 요구하지 않는데 오라클이 왜 더 문제가 되었습니까? 대답은 사용자가 필요할 수 있다는 것입니다. 역사가와 천문학 자들은이 혼성 시스템을 다발성 그레고리력 대신 사용합니다. (이것은 Java 용 GregorianCalendar 클래스를 구현할 때 Sun이 선택한 기본 옵션입니다. 이름에도 불구하고 GregorianCalendar는 하이브리드 달력입니다.)
또한 Windows는 지난 3 월 -4 월 또는 10 월 -11 월의 특정 날짜에 대해 UTC를 미국 현지 시간으로 올바르게 변환하는 방법을 더 이상 알지 못합니다. 해당 날짜의 UTC 기반 타임 스탬프는 이제 다소 의미가 없습니다. 미국 정부의 최신 DST 규칙 이전에 OS가 단순히 타임 스탬프 처리를 거부하는 것은 매우 어색한 일이므로 일부는 잘못 처리합니다. SQL Server는 1753 년 이전의 날짜를 처리하지 않기 때문에 날짜를 올바르게 처리하기 위해 많은 추가 특수 논리가 필요하며이를 잘못 처리하고 싶지 않습니다.