Qual è il significato di 1/1/1753 in SQL Server?

Question

Perché 1753? Cosa hanno contro il 1752? Il mio grande grande grande grande grande grande bisnonno sarebbe molto offeso.

Answer 1

La decisione di utilizzare il 1 ° gennaio 1753 (1753-01-01) come valore di data minima per un datetime in SQL Server torna al suo Sybase origins.

Il significato della data stessa può essere attribuito a quest'uomo.

Philip Stanhope, quarto conte di Chesterfield. Chi guidò lo Calendar (New Style) Act 1750 attraverso il Parlamento britannico. Questo ha legiferato per l'adozione del calendario gregoriano per la Gran Bretagna e le sue poi colonie.

C'erano alcuni missing days nel calendario britannico nel 1752 quando l'adeguamento fu finalmente fatto dal calendario Giuliano. 3 settembre 1752 al 13 settembre 1752 furono persi.

Kalen Delaney explained la scelta in questo modo

Così, con 12 giorni persi, come si può date di calcolo? Ad esempio, come è possibile calcolare il numero di giorni tra , 12 ottobre 1492 e 4 luglio 1776? Sei includi quelli che mancano 12 giorni? Per evitare di dover risolvere questo problema, originali server sviluppatori Sybase SQL deciso di non permettere date prima di 1753. È possibile memorizzare precedenti date utilizzando campi di carattere, ma non è possibile utilizzare tutte le funzioni di data e ora con l' date precedenti che si memorizza nei campi dei caratteri.

La scelta del 1753 sembra un po 'anglocentrico tuttavia come many catholic countries in Europa erano state utilizzando il calendario per 170 anni prima dell'attuazione britannico (originariamente in ritardo a causa dell'opposizione by the church). Viceversa molti paesi non hanno riformato i loro calendari fino a molto tempo dopo, nel 1918 in Russia. Infatti la rivoluzione d'ottobre del 1917 iniziò il 7 novembre sotto il calendario gregoriano.

Entrambi datetime e il nuovo tipo di dati datetime2 menzionati in Joe's answer non tentare di tenere conto di queste differenze locali e semplicemente utilizzare il calendario gregoriano.

Quindi, con la più ampia gamma di datetime2

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

Returns

Sep 8 1752 12:00AM 

Un ultimo punto con il tipo di dati datetime2 è che usa il proleptic Gregorian calendar proiettata all'indietro per ben prima che in realtà è stato inventato in modo è di uso limitato nel trattare date storiche.

Questo contrasta con altre implementazioni software come la classe Java Gregorian Calendar che per impostazione predefinita segue il calendario giuliano per le date fino al 4 ottobre 1582 e poi salta al 15 ottobre 1582 nel nuovo calendario gregoriano.Gestisce correttamente il modello giuliano di anno bisestile prima di quella data e il modello gregoriano dopo quella data. La data del cutover può essere modificata dal chiamante chiamando lo setGregorianChange().

Un articolo abbastanza divertente che discute alcune altre peculiarità con l'adozione del calendario can be found here.

Answer 2

1752 è stato l'anno della Gran Bretagna passando dal calendario giuliano al calendario gregoriano. Credo che due settimane nel settembre 1752 non siano mai avvenute di conseguenza, il che ha implicazioni per le date in quell'area generale.

Una spiegazione: http://uneasysilence.com/archive/2007/08/12008/ (Internet Archive version)

Answer 3

tua grande grande grande grande grande grande grande nonno dovrebbe eseguire l'aggiornamento a SQL Server 2008 e utilizzare il tipo di dati DateTime2, che sostiene date nell'intervallo: 0001-01-01 attraverso 9999-12-31.

Answer 4

Per inciso, Windows non sa più come convertire correttamente l'ora locale UTC in USA per determinate date a marzo/aprile o ottobre/novembre degli anni passati. I timestamp basati su UTC da quelle date sono ora un po 'privi di senso. Sarebbe molto icky per il sistema operativo semplicemente rifiutarsi di gestire qualsiasi timestamp prima dell'ultimo set di regole dell'ora legale del governo degli Stati Uniti, quindi si limita a gestirne alcune errate. SQL Server si rifiuta di elaborare le date prima del 1753 perché sarebbe necessaria molta logica speciale aggiuntiva per gestirle correttamente e non vuole gestirle in modo errato.

Answer 5

Questa è l'intera storia del problema della data e di come i grandi DBMS gestivano questi problemi.

Nel periodo compreso tra 1 dC e oggi, il mondo occidentale ha effettivamente utilizzato due calendari principali: il calendario giuliano di Giulio Cesare e il calendario gregoriano di Papa Gregorio XIII. I due calendari differiscono rispetto a una sola regola: la regola per decidere cos'è un anno bisestile . Nel calendario giuliano, tutti gli anni divisibili per quattro sono gli anni bisestili . Nel calendario gregoriano, tutti gli anni divisibili per quattro sono gli anni bisestili , salvo che gli anni divisibili per 100 (ma non divisibili per 400) non sono anni bisestili. Quindi, gli anni 1700, 1800 e 1900 saltavano anni nel calendario giuliano ma non nel calendario gregoriano, mentre gli anni negli anni 1600 e 2000 sono bisestili in entrambi i calendari.

Quando papa Gregorio XIII introdusse il suo calendario nel 1582, ha anche diretto che i giorni tra il 4 ottobre 1582 e 15 ottobre 1582, dovrebbe essere saltato, cioè, ha detto che il giorno dopo il 4 ottobre dovrebbe essere il 15 ottobre. Molti paesi hanno tuttavia ritardato il cambio. Inghilterra e le sue colonie non passarono da Giuliano a Gregoriano che contava fino al 1752, quindi per loro, le date saltate erano tra il 4 settembre e il 14 settembre 1752. Altri paesi passati in altri momenti, ma 1582 e 1752 sono il date rilevanti per i DBMS che stiamo discutendo di .

Quindi, due problemi sorgono con l'aritmetica della data quando si torna indietro di molti anni. Il primo è, dovrebbe balzare anni prima che l'interruttore venga calcolato secondo le regole di Giuliano o Gregoriano? Il secondo problema è, quando e come devono essere gestiti i giorni saltati?

Questo è come il Big DBMS gestire queste domande:

• Fingere non c'era alcun interruttore. Questo è ciò che richiede lo standard SQL , sebbene il documento standard non sia chiaro: si dice semplicemente che le date sono "vincolate dalle regole naturali per le date che utilizzano il calendario " le "regole naturali" sono. Questa è l'opzione scelta da DB2. Quando c'è il pretesto che le regole di un singolo calendario siano sempre applicate anche a volte in cui nessuno ha sentito parlare del calendario , il termine tecnico è che un calendario "prolettico" è in vigore . Quindi, per esempio, potremmo dire che DB2 segue un calendario gregoriano proletico .
• Evitare completamente il problema. Microsoft e Sybase impostano i loro valori di data minima al 1 ° gennaio 1753, oltrepassando in modo sicuro l'ora che America ha scambiato i calendari. Ciò è difendibile, ma a partire dal momento in cui i reclami temporali relativi a presentano che questi due DBMS mancano di un'utile funzionalità che gli altri DBMS hanno e che richiede lo standard SQL .
• Seleziona 1582. Questo è ciò che Oracle ha fatto. Un utente Oracle avrebbe trovare che l'espressione aritmetica data 15 ottobre 1582 meno ottobre 4 1582 restituisce un valore di 1 giorno (perché il 5-14 ottobre non esiste) e che la data 29 febbraio 1300 è valida (perché il Si applica la regola Julian bisestile ). Perché Oracle ha avuto problemi extra quando lo standard SQL non sembra averlo richiesto? La risposta è che gli utenti potrebbero richiedere . Gli storici e gli astronomi usano questo sistema ibrido invece di un calendario gregoriano prolettico. (Questa è anche l'opzione predefinita che Sun prese in sede di attuazione della classe GregorianCalendar per Java nonostante il nome, è un calendario GregorianCalendar ibrido.)

Fonte 1 e 2