1/1/1753'ün SQL Server'daki önemi nedir?

Neden 1753? 1752'ye karşı ne var? Benim büyük büyük büyük büyük büyük büyük büyük büyükbabam çok rahatsız olurdu.

1753-01-01SQL Server'da bir tarih için minimum tarih değeri olarak 1 Ocak 1753 ( ) kullanma kararı Sybase kökenlerine kadar gider .

Ancak tarihin kendisinin önemi bu adama atfedilebilir.

Philip Stanhope, Chesterfield'ın 4. Earl'ü. Kim kumanda Takvim (Yeni Stil) Yasası 1750 İngiliz Parlamentosu aracılığıyla. Bu, Britanya ve o zamanki sömürgeleri için Gregoryen takviminin kabulü için yasalaştı.

1752'de İngiliz takviminde, Julian takviminden ayarlamaların yapıldığı bazı eksik günler _{(internet arşiv bağlantısı)} vardı. 3 Eylül 1752 - 13 Eylül 1752 kaybedildi.

Kalen Delaney seçimi bu şekilde açıkladı

Peki, 12 gün kaybolduğunda tarihleri ​​nasıl hesaplayabilirsiniz? Örneğin, 12 Ekim 1492 ile 4 Temmuz 1776 arasındaki gün sayısını nasıl hesaplayabilirsiniz? Eksik olan 12 günü ekliyor musunuz? Bu sorunu çözmek zorunda kalmamak için, özgün Sybase SQL Server geliştiricileri 1753'ten önceki tarihlere izin vermemeye karar verdiler. Karakter alanlarını kullanarak önceki tarihleri ​​depolayabilirsiniz, ancak karakterde depoladığınız daha önceki tarihlerle herhangi bir datetime işlevi kullanamazsınız alanlar.

1753'ün seçimi biraz öfkeli görünüyor, ancak Avrupa'daki birçok Katolik ülke takvimi İngiliz uygulamasından önce 170 yıl boyunca kullanıyordu (başlangıçta kilisenin muhalefeti nedeniyle gecikti ). Tersine, birçok ülke takvimlerini 1918'de Rusya'ya kadar reform yapmadı. Nitekim 1917 Ekim Devrimi 7 Kasım'da Gregoryen takvimi altında başladı.

Hem Joe'nun cevabında bahsedilen datetimeyeni datetime2veri türü bu yerel farklılıkları hesaba katmaya çalışmıyor ve sadece Gregoryen Takvimini kullanıyor.

Yani daha geniş bir yelpazede datetime2

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

İadeler

Sep  8 1752 12:00AM

datetime2Veri türüyle ilgili son bir nokta , aslında icat edilmeden önce geriye doğru yansıtılan proleptik Gregoryen takvimini kullanmasıdır, bu nedenle tarihi tarihlerle uğraşmada sınırlı kullanımdır.

Bu , 4 Ekim 1582'ye kadar olan tarihler için Julian Takvimini takip eden ve ardından yeni Gregoryen takviminde 15 Ekim 1582'ye atlayan Java Gregorian Calendar sınıfı gibi diğer Yazılım uygulamalarıyla çelişir . Julian, o tarihten önceki yıl sıçrama modelini ve o tarihten sonra Gregoryen modelini doğru şekilde işler. Kesinti tarihi arayan tarafından aranarak değiştirilebilir setGregorianChange().

Takvimin benimsenmesi ile biraz daha tuhaflıkları tartışan oldukça eğlenceli bir makale burada bulunabilir .

Büyük büyük büyük büyük büyük büyük büyük dedeniz SQL Server 2008'e yükseltmeli ve 0001-01-01 - 9999-12-31 aralığındaki tarihleri ​​destekleyen DateTime2 veri türünü kullanmalıdır .

1752 Britanya'nın Julian'dan Gregoryen takvimine geçtiği yıldı. Eylül 1752'de iki haftanın sonuç olarak hiçbir zaman gerçekleşmediğine inanıyorum, ki bu genel alandaki tarihler için sonuçları var.

Bir açıklama: http://uneasysilence.com/archive/2007/08/12008/ ( İnternet Arşivi sürümü )

Tarih sorununun nasıl olduğu ve Büyük DBMS'lerin bu sorunları nasıl ele aldığı budur.

MS 1 ile bugün arasındaki dönemde, Batı dünyası aslında iki ana takvim kullandı: Julius Caesar'ın Julian takvimi ve Papa Gregory XIII'in Gregoryen takvimi. İki takvim yalnızca bir kurala göre farklılık gösterir: artık yılın ne olduğuna karar verme kuralı. Julian takviminde, dörde bölünebilen tüm yıllar artık yıllardır. Gregoryen takviminde, dörde bölünebilen tüm yıllar artık yıllardır, ancak 100'e bölünebilen (ancak 400'e bölünemeyen) yıllar artık yıllar değildir. Böylece 1700, 1800 ve 1900 yılları Julian takviminde artık yıllardı, Gregoryen takviminde değil, 1600 ve 2000 yılları her iki takvimde de artık yıllardı.

Papa XIII.III, takvimini 1582'de tanıttığında, 4 Ekim 1582 ile 15 Ekim 1582 arasındaki günlerin atlanması gerektiğini, yani 4 Ekim'den sonraki günün 15 Ekim olması gerektiğini söyledi. gerçi değişti. İngiltere ve kolonileri Julian'dan Gregoryen hesaplamasına 1752'ye kadar değişmedi, bu yüzden onlar için atlanan tarihler 4 Eylül ile 14 Eylül 1752 arasındaydı. Diğer ülkeler diğer zamanlarda değişti, ancak 1582 ve 1752, Tartıştığımız DBMS'ler.

Böylece, tarih aritmetiği ile yıllarca geriye gittiğinde iki problem ortaya çıkar. Birincisi, geçişten önceki yıllar, Julian veya Gregoryen kurallarına göre hesaplanmalı mıdır? İkinci sorun, atlanan günlerin ne zaman ve nasıl ele alınması gerektiğidir.

Büyük DBMS'ler şu soruları şu şekilde ele alır:

• Anahtar yokmuş gibi davran. Standart belgenin belirsiz olmasına rağmen, SQL Standardının gerektirdiği şey budur: Sadece tarihlerin "Gregoryen takvimini kullanan tarihler için doğal kurallarla kısıtlandığını" ("doğal kurallar" ne olursa olsun) söylüyor. Bu, DB2'nin seçtiği seçenektir. Tek bir takvimin kurallarının, kimsenin takvimi duymadığı zamanlarda bile her zaman uygulandığı iddiası olduğunda, teknik terim "proleptik" takvimin yürürlükte olduğudur. Örneğin, DB2'nin proleptik bir Gregoryen takvimi izlediğini söyleyebiliriz.
• Sorunu tamamen ortadan kaldırın. Microsoft ve Sybase, minimum tarih değerlerini 1 Ocak 1753'te, Amerika'nın takvimleri değiştirdiği zamanın ötesine geçtiler. Bu savunulabilir, ancak zaman zaman şikayetler, bu iki DBMS'nin diğer DBMS'lerin sahip olduğu ve SQL Standardının gerektirdiği yararlı bir işlevselliğe sahip olmadığını göstermektedir.
• 1582'yi seçin. Oracle bunu yaptı. Bir Oracle kullanıcısı, 15 Ekim 1582 eksi 4 Ekim 1582 tarih-aritmetik ifadesinin 1 günlük bir değer verdiğini (5–14 Ekim mevcut olmadığı için) ve 29 Şubat 1300 tarihinin geçerli olduğunu (Julian sıçrama- yıl kuralı geçerlidir). SQL Standardı gerektirmediğinde Oracle neden fazladan soruna gitti? Cevap, kullanıcıların buna ihtiyaç duyabileceğidir. Tarihçiler ve astronomlar proleptik bir Gregoryen takvimi yerine bu hibrit sistemi kullanıyorlar. (Bu aynı zamanda Sun'ın Java için GregorianCalendar sınıfını uygularken seçtiği varsayılan seçenektir - adına rağmen GregorianCalendar karma bir takvimdir.)

Kaynak 1 ve 2

Bu arada, Windows artık geçmiş yılların Mart / Nisan veya Ekim / Kasım aylarında belirli tarihler için UTC'yi ABD yerel saatine nasıl doğru dönüştüreceğini bilmiyor. Bu tarihlerden UTC tabanlı zaman damgaları artık biraz saçma. İşletim sisteminin ABD hükümetinin en son DST kuralları setinden önce herhangi bir zaman damgasını işlemeyi reddetmesi çok zordur, bu yüzden bazılarını yanlış işler. SQL Server, 1753'ten önceki tarihleri ​​işlemeyi reddeder, çünkü bunları doğru şekilde işlemek için çok sayıda ekstra özel mantık gerekir ve bunları yanlış işlemek istemez.