Re: COleDateTime base date 30 Dec 1899. Why??

I think it ultimately has to do with Lotus 123, whose date format Excel
copied, including the bug which considered 1900 to be a leap year. Consider
this little program:

#include <afx.h>
#include <ATLComTime.h>
#include <stdio.h>

void print(double serial)
{
  COleDateTime d;
  d.m_status = COleDateTime::valid;
  d.m_dt = serial;
  printf("%f = %s\n", d.m_dt, (LPCSTR) d.Format());
}

int main()
{
  print(59);
  print(60);
  print(61);
  print(62);
}

Its output is:

59.000000 = 2/27/1900
60.000000 = 2/28/1900
61.000000 = 3/1/1900
62.000000 = 3/2/1900

Looks fine. Now consider the same values in Excel:

59 2/28/1900 12:00:00 AM
60 2/29/1900 12:00:00 AM
61 3/1/1900 12:00:00 AM
62 3/2/1900 12:00:00 AM

Again, 1900 was not a leap year, so Excel 2007 is still copying the Lotus
bug and I suppose always will. Notice that the formatted COleDateTime
values are one day less than the Excel values for serial numbers < 61, and
that they agree for serial numbers >= 61; the COleDateTime does not
incorrectly consider 1900 a leap year. So based on this, I'd guess that the
designers of the OLE DATE type wanted to be compatible with Excel, but they
didn't want to copy the Lotus bug, and they were willing to accept being
incompatible with Excel for this small range of early dates. Given the
popularity of Lotus 123 back in the day, the Excel designers no doubt felt
they couldn't afford even this small degree of incompatibility.