Why is 1899-12-30 the zero date in Access / SQL Server instead of 12/31?

Question

More out of curiosity than any real problem; the question came up today and I know I\'ve seen 1899-12-30 used as a \"default\" date and a zero date in Access and older SQL S

Answer 1

Maintaining compatibility with Lotus 1-2-3 back in the day, which had a bug in that it thought the year 1900 was a leap year (or pretended?).

The explanation is too long to quote, but for the sake of curiosity, here are some snippets.

• http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53013.aspx

• http://www.joelonsoftware.com/items/2006/06/16.html

1900 wasn't a leap year.

"It's a bug in Excel!" I exclaimed.

"Well, not really," said Ed. "We had to do it that way because we need to be able to import Lotus 123 worksheets."

"So, it's a bug in Lotus 123?"

"Yeah, but probably an intentional one. Lotus had to fit in 640K. That's not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That's really fast and easy. The Lotus guys probably figured it didn't matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back."

• http://www.cpearson.com/excel/datetime.htm

Actually, this number is one greater than the actual number of days. This is because Excel behaves as if the date 1900-Feb-29 existed. It did not. The year 1900 was not a leap year (the year 2000 is a leap year). In Excel, the day after 1900-Feb-28 is 1900-Feb-29. In reality, the day after 1900-Feb-28 was 1900-Mar-1 . This is not a "bug". Indeed, it is by design. Excel works this way because it was truly a bug in Lotus 123. When Excel was introduced, 123 has nearly the entire market for spreadsheet software. Microsoft decided to continue Lotus' bug, in order to fully compatible. Users who switched from 123 to Excel would not have to make any changes to their data. As long as all your dates later than 1900-Mar-1, this should be of no concern.

Answer 2

To best of my knowledge, date type did not exist in "older SQL Server". It was introduced in SQL Server 2008 having zero date value corresponding to 0001/01/01.

select cast(0x000000 as date),cast(CONVERT(date, '0001/01/01') as varbinary(max)) 
----------     --------
--0001-01-01   0x000000

The statements of questions do not make sense. Were date type existed in " older SQL Server', it would have implied the broken backward compatibility of date type in SQL Server 2008.

There is no point in answering (and upvote posts) in the question with undefined or incorrectly defined terms.

Answer 3

SQL Server appears to return this date as a default if it cannot contact it's defined time source.

I've had this happen during cluster failover incidents when my biometric time attendance system is running / being used.

To defeat local clock manipulation, someone clocks in, I ask the SQL cluster instance what time it is.

It can't get a valid active time source and returns this date.

Workaround for me is straight forward by checking for this date in my GetServerTime Sub and using local PC time if this 'default' is returned.

I've seen this with SQL 2000/2005/2008, all via ADO and VB6.