This issue stems from the way excel stores dates and a bug that harkens back to Lotus 123.
From http://www.cpearson.com/excel/datetime.htm
Dates
The integer portion of the number, ddddd, represents the number of
days since 1900-Jan-0. For example, the date 19-Jan-2000 is stored as
36,544, since 36,544 days have passed since 1900-Jan-0. The number 1
represents 1900-Jan-1. It should be noted that the number 0 does not
represent 1899-Dec-31. It does not. If you use the MONTH function
with the date 0, it will return January, not December. Moreover, the
YEAR function will return 1900, not 1899.
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.
This answer has more detail though I've just been converting the date to string which excel seems to parse correctly.
converted = str(datetime.date(1900, 1, 1))