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

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

La decisione di utilizzare il 1 ° gennaio 1753 ( 1753-01-01) come valore di data minimo per un datetime in SQL Server risale alle origini di Sybase .

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

Philip Stanhope, 4º conte di Chesterfield. Chi ha diretto il Calendar (New Style) Act 1750 attraverso il Parlamento britannico. Ciò legiferava per l'adozione del calendario gregoriano per la Gran Bretagna e le sue allora colonie.

C'erano alcuni giorni mancanti _{(link all'archivio internet)} nel calendario britannico nel 1752, quando la regolazione fu finalmente fatta dal calendario giuliano. Dal 3 settembre 1752 al 13 settembre 1752 andarono persi.

Kalen Delaney ha spiegato la scelta in questo modo

Quindi, con 12 giorni persi, come puoi calcolare le date? Ad esempio, come è possibile calcolare il numero di giorni tra il 12 ottobre 1492 e il 4 luglio 1776? Includete quei 12 giorni mancanti? Per evitare di dover risolvere questo problema, gli sviluppatori originali di Sybase SQL Server hanno deciso di non consentire le date precedenti al 1753. È possibile memorizzare date precedenti utilizzando i campi carattere, ma non è possibile utilizzare alcuna funzione datetime con le date precedenti memorizzate nel carattere campi.

La scelta del 1753 sembra in qualche modo anglocentrica, tuttavia, poiché molti paesi cattolici in Europa utilizzavano il calendario da 170 anni prima dell'implementazione britannica (originariamente ritardata a causa dell'opposizione della chiesa ). Al contrario, molti paesi non riformarono i loro calendari fino a molto più tardi, nel 1918, in Russia. In effetti, la rivoluzione di ottobre del 1917 iniziò il 7 novembre sotto il calendario gregoriano.

Entrambi datetimee il nuovo datetime2tipo di dati menzionato nella risposta di Joe non tentano di tenere conto di queste differenze locali e usano semplicemente il calendario gregoriano.

Quindi con la gamma più ampia di datetime2

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

ritorna

Sep  8 1752 12:00AM

Un ultimo punto con il datetime2tipo di dati è che utilizza il proletico calendario gregoriano proiettato all'indietro ben prima che fosse effettivamente inventato, quindi è di scarsa utilità nel gestire date storiche.

Ciò è in contrasto con altre implementazioni software come la classe del calendario gregoriano Java che per impostazione predefinita segue il calendario giuliano per date fino al 4 ottobre 1582 e poi salta al 15 ottobre 1582 nel nuovo calendario gregoriano. Gestisce correttamente il modello giuliano dell'anno bisestile prima di quella data e il modello gregoriano dopo quella data. La data del ritaglio può essere modificata dal chiamante chiamando setGregorianChange().

Un articolo abbastanza divertente che discute alcune altre peculiarità con l'adozione del calendario può essere trovato qui .

Il tuo fantastico bis-bis-bis-bis-bisnonno dovrebbe eseguire l'upgrade a SQL Server 2008 e utilizzare il tipo di dati DateTime2 , che supporta le date nell'intervallo: da 0001-01-01 a 9999-12-31.

Il 1752 fu l'anno in cui la Gran Bretagna passò dal calendario giuliano al calendario gregoriano. Credo che due settimane nel settembre 1752 non siano mai avvenute, il che ha implicazioni per le date in quell'area generale.

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

Questa è l'intera storia di come fosse il problema della data e di come i grandi DBMS hanno gestito questi problemi.

Nel periodo tra il 1 d.C. 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 che anno bisestile. Nel calendario giuliano, tutti gli anni divisibili per quattro sono anni bisestili. Nel calendario gregoriano, tutti gli anni divisibili per quattro sono anni bisestili, tranne che gli anni divisibili per 100 (ma non divisibili per 400) non sono anni bisestili. Pertanto, gli anni 1700, 1800 e 1900 sono anni bisestili nel calendario giuliano ma non nel calendario gregoriano, mentre gli anni 1600 e 2000 sono anni bisestili in entrambi i calendari.

Quando Papa Gregorio XIII introdusse il suo calendario nel 1582, ordinò anche che i giorni tra il 4 ottobre 1582 e il 15 ottobre 1582 dovessero essere saltati, cioè disse che il giorno dopo il 4 ottobre dovrebbe essere il 15 ottobre. Molti paesi ritardato cambio, però. L'Inghilterra e le sue colonie non passarono da Julian alla resa dei conti gregoriana fino al 1752, quindi per loro, le date saltate furono tra il 4 settembre e il 14 settembre 1752. Altri paesi passarono altre volte, ma il 1582 e il 1752 sono le date rilevanti per DBMS di cui stiamo discutendo.

Pertanto, due problemi sorgono con l'aritmetica della data quando si risale a molti anni fa. Il primo è, bisognerebbe saltare anni prima che il passaggio venga calcolato secondo le regole giuliana o gregoriana? Il secondo problema è, quando e come devono essere gestiti i giorni saltati?

Ecco come i Big DBMS gestiscono queste domande:

• Fai finta che non ci fosse alcun interruttore. Questo è ciò che sembra richiedere lo standard SQL, anche se il documento standard non è chiaro: dice solo che le date sono "vincolate dalle regole naturali per le date usando il calendario gregoriano", qualunque siano le "regole naturali". Questa è l'opzione scelta da DB2. Quando si fa finta che le regole di un singolo calendario siano sempre state applicate anche in periodi in cui nessuno ha sentito parlare del calendario, il termine tecnico è che è in vigore un calendario "prolettico". Quindi, ad esempio, potremmo dire che DB2 segue un calendario gregoriano prolettico.
• Evita del tutto il problema. Microsoft e Sybase hanno impostato i valori minimi della data al 1 ° gennaio 1753, in modo sicuro oltre il tempo in cui l'America ha cambiato calendario. Ciò è difendibile, ma di tanto in tanto emergono lamentele sul fatto che questi due DBMS mancano di una funzionalità utile degli altri DBMS e che lo standard SQL richiede.
• Scegli 1582. Ecco cosa fece Oracle. Un utente Oracle troverebbe che l'espressione aritmetica data 15 ottobre 1582 meno 4 ottobre 1582 restituisce un valore di 1 giorno (perché il 5–14 ottobre non esiste) e che la data 29 febbraio 1300 è valida (perché il salto di Julian- si applica la regola dell'anno). Perché Oracle ha avuto ulteriori problemi quando lo standard SQL non sembra richiederlo? La risposta è che gli utenti potrebbero richiederlo. Gli storici e gli astronomi usano questo sistema ibrido invece di un proletico calendario gregoriano. (Questa è anche l'opzione predefinita scelta da Sun durante l'implementazione della classe GregorianCalendar per Java, nonostante il nome, GregorianCalendar è un calendario ibrido.)

Sorgente 1 e 2

Per inciso, Windows non sa più come convertire correttamente UTC nell'ora locale degli Stati Uniti per determinate date in marzo / aprile o ottobre / novembre degli anni passati. I timestamp basati su UTC di tali date sono ora in qualche modo privi di senso. Sarebbe molto spiacevole per il sistema operativo semplicemente rifiutare di gestire eventuali timestamp prima dell'ultima serie di regole dell'ora legale del governo degli Stati Uniti, quindi ne gestisce semplicemente alcune errate. SQL Server si rifiuta di elaborare le date prima del 1753 perché sarebbe necessaria molta logica speciale extra per gestirle correttamente e non vuole gestirle in modo errato.