In that case, use the framework library function DateTime.FromOADate() .
This function encapsulates all the specifics, and does bounds checking.
For its historical value, here is a possible implementation:
(C#)
public static DateTime FromExcelSerialDate(int SerialDate)
{
if (SerialDate > 59) SerialDate -= 1; //Excel/Lotus 2/29/1900 bug
return new DateTime(1899, 12, 31).AddDays(SerialDate);
}
VB
Public Shared Function FromExcelSerialDate(ByVal SerialDate As Integer) As DateTime
If SerialDate > 59 Then SerialDate -= 1 ' Excel/Lotus 2/29/1900 bug
Return New DateTime(1899, 12, 31).AddDays(SerialDate)
End Function
[Update]:
Hmm... A quick test of that shows it's actually two days off. Not sure where the difference is.
Okay: problem fixed now. See the comments for details.
void ExcelSerialDateToDMY(int nSerialDate, int &nDay,
int &nMonth, int &nYear)
{
// Excel/Lotus 123 have a bug with 29-02-1900. 1900 is not a
// leap year, but Excel/Lotus 123 think it is...
if (nSerialDate == 60)
{
nDay = 29;
nMonth = 2;
nYear = 1900;
return;
}
else if (nSerialDate < 60)
{
// Because of the 29-02-1900 bug, any serial date
// under 60 is one off... Compensate.
nSerialDate++;
}
// Modified Julian to DMY calculation with an addition of 2415019
int l = nSerialDate + 68569 + 2415019;
int n = int(( 4 * l ) / 146097);
l = l - int(( 146097 * n + 3 ) / 4);
int i = int(( 4000 * ( l + 1 ) ) / 1461001);
l = l - int(( 1461 * i ) / 4) + 31;
int j = int(( 80 * l ) / 2447);
nDay = l - int(( 2447 * j ) / 80);
l = int(j / 11);
nMonth = j + 2 - ( 12 * l );
nYear = 100 * ( n - 49 ) + i + l;
}