August 10, 2011 at 4:08 pm
Revenant (8/10/2011)
Tom.Thomson (8/10/2011)
. . .Not in most countries except Britain (note single t), in all countries including Britain. Datetime2 uses the Gregorian calendar, not any other calendar, so it is not a locale dependent type.
Hmm... maybe it is not quite Gregorian. If you run this, --
DECLARE @type2 DATETIME2(7) = '1582-10-10';PRINT DATEPART( dw, @type2 );
you will get 1, i.e., Monday, but that is wrong because there was no October 10 in 1582.
Actually if you have Monday as day 1 you will get 7, because that date is a Sunday in the Gregorian calendar. I suspect you have the US default (datefirst = 7, so dw=1 on Sunday), since you presumably got 1.
I guess you and I mean different things by "The Gregorian Calendar"; if "Gregorian Calendar" means the national calendar of the United Kingdom of Poland and Lithuania, or some of the Italian states, or Spain, or Portugal that date didn't exist (in the national calendars of everywhere else in the Western world it did). If you mean the calendar using the 365.2525 day year in common use throughout the western world, in which today is 10 August 2011, extended backwards and forwards according to its regular rules without limit (which is the most common meaning, I believe) 10 Oct 1582 certainly does exist in that calendar.
Using calendars of particular nations can lead to strange results. For example in England the months of January and February did not legally exist in 1751, but they did exist in Scotland (Scottish Jan 1751 was English Jan 1750; almost everyone in England already used the Scottish dating for everything except legal documents and taxation; it was just the legal system in England that was out of step). Scotland had begun the year on 1 Jan since 1600, while up to and including 1751 England began the year on 25th March. That's where we get our 6 April to 5 April taxation year from - it was 5 April to 4 April from 1752 to 1799, then from 6 April to 5 April from 1800 to 1899 in order to retain the same Julian date; but it wasn't adjusted in 1900, which was the next year when an adjustment would have been needed to maintain the Julian connection (whether because the 1751 act was interpreted differently or because the powers that be had forgotten that that act had been interpreted in 1800 as demanding such an adjustment).
Tom
August 10, 2011 at 7:28 pm
That's a great post, Tom, showing examples of the variety in calendar usage. It's truly fascinating in a way that appeals to my inner "geek". It also provides a great sample of reasons to consider DATETIME2 simply a data type and nothing more. It holds values of dates following certain construction rules (number of days in a month, which is a leap year....), but does not attempt to codify the varieties of calendar adjustments made in different locales over the centuries. I think that's what you were saying too, in the last sentence of the first paragraph.
I think that's a fair thing for MS to have done. If I'm storing dates of historical events in the eighteenth century, then I ought to make any duration calculations aware of the Old Style/New Style break in 1752, or any other anomalies like the Scottish/English calendar difference.
August 10, 2011 at 9:58 pm
I logged that October 5-14, 1582, unaccounted-for gap as a bug against Windows. (SQL Server gets the weekday via a WinAPI call.)
I was told that this will be “soon” corrected for the cultures (languages) that were on the Roman calendar at that time. Win guys are not exactly sure what to do about countries that converted later; most notably Russian Orthodoxy, which converted only after the October Revolution of 1917. (What do you do if the date and time are marked as GMT but the culture is one of the Eastern Orthodoxies? Any suggestions for precedence of calculation?)
This goes all the way back to The Bard and his oft-quoted “time is out of joint,” which alluded to the fact that when he wrote Hamlet, the English calendar was out of sync with the Roman one.
I guess this means that someone will have to think through comparisons of dates on servers that are set to different cultures. (The mentioned October Revolution, which was logged on October 25, 1917, is now celebrated on November 7.)
Never a dull moment.
August 11, 2011 at 9:38 am
Revenant (8/10/2011)
I was told that this will be “soon” corrected for the cultures (languages) that were on the Roman calendar at that time. Win guys are not exactly sure what to do about countries that converted later; most notably Russian Orthodoxy, which converted only after the October Revolution of 1917. (What do you do if the date and time are marked as GMT but the culture is one of the Eastern Orthodoxies? Any suggestions for precedence of calculation?) [/quote
They are going to have real fun for Italy, which at the time was a bunch of city-states some of which converted in 1582 and some of which didn't. Also with Germany and bits of Austria (Holy Roman Empire) which converted piece-meal at later dates. And with the GB locale (different year numbers in different countries), the Netherlands, France, and Denmark. Even in the USA Texas converted to dates back when it was still Spanish, much of the rest of the USA rather later, and the Louisana Territory switched at yet another time. I guess the best they can do (unless they have the sense to do nothing) will be to cobble together some arbitrary meaningless mess which will offend various cultures quite seriously, and pretend they've done something useful.
This goes all the way back to The Bard and his oft-quoted “time is out of joint,” which alluded to the fact that when he wrote Hamlet, the English calendar was out of sync with the Roman one.
It goes back a long way before that. Some states used 1Jan as official year beginning from more than 300 years before Shakespeare, but the Roman official year never began then.
I guess this means that someone will have to think through comparisons of dates on servers that are set to different cultures. (The mentioned October Revolution, which was logged on October 25, 1917, is now celebrated on November 7.)
Never a dull moment.
Indeed not!
Tom
September 28, 2011 at 7:57 am
I am disagree with the correct answer of this query..
I got the following result after running the same in Msg window...
1752-09-09 00:00:00.0000000
I use "Microsoft SQL server 2008 R2", Please Explain....
September 28, 2011 at 8:12 am
hardikssit1 (9/28/2011)
I am disagree with the correct answer of this query..I got the following result after running the same in Msg window...
1752-09-09 00:00:00.0000000
I use "Microsoft SQL server 2008 R2", Please Explain....
The explanation is in the answer to the question. This wasn't meant to be an uber-serious QOTD. It was meant as a fun little brain teaser. In certain calendars, the date doesn't technically exist. Which makes it even more interesting that MS says that it does.
February 27, 2012 at 8:44 am
Great question on the DATETIME2 that supports larger precision times and date ranges.
Thanks.
Viewing 7 posts - 76 through 81 (of 81 total)
You must be logged in to reply to this topic. Login to reply