C # DateTime AddDays Unexpected Offset

Question

I have a very simple DateTime object that is set to date 01-01-0001. I get the value added to this DateTime after a few days. I see an unexpected bias in my results, albeit two days. Let it pretend that I print out the results of a call to AddDays (), for example:

DateTime myDateTime = DateTime.Parse("01-01-0001 00:00:00"); Console.WriteLine(myDateTime.AddDays(735768.0)); 

With the above value (735768.0), I expect the output to "6/18/2015 12:00:00 AM". However, instead I get "6/20/2015 12:00:00 AM". When I go to the following website and calculate the duration in days between 01-01-0001 → 06/18/2015, I get a value of 735 768 days, as expected:

http://www.timeanddate.com/date/durationresult.html?m1=01&d1=01&y1=0001&m2=06&d2=18&y2=2015

Am I doing something wrong, or is something happening under the hood that I don’t know about?

In case you are interested, 735 768 represents the first value of the data I work with. It is expected that the data will start from 06/18/2012 00:00:00.

Edit: I should point out that I just presented this particular website as an example of a conflicting source. Other sites, including the government weather agency, I receive data from everyone, give me 06-18-2015. This does not mean that C # is incorrect. I'm more curious where this bias came from and why.

Answer 1

Timeanddate.com takes into account a calendar change from Julian to Gregorian, which explains the discrepancy.

You can see this change if you look at the difference between 01/01/1752 and 01/01/1753 at timeanddate.com:

• The formula for leap years in the Julian calendar is "every year divided by 4". This means that there are a few more leap years in the calculation of timeanddate.com between year 1 and year 1752, when the calendar changes. This allows you to calculate .NET before 1753 for 11 days.
• Until 1752, England and the east coast of the United States used the Julian calendar . The consequence of this change is that 1752 was only 355 days. This calculation is not taken into account when calculating .NET, so at this point, calculating .NET is two days ahead.

According to this answer from John Skeet , DateTime uses exclusively the Gregorian calendar. This is why the above subtleties are not reflected in .NET calculations.

Answer 2

.NET gives you the “correct” answer - noting that the “correct” one assumes a purely Gregorian calendar, as Andrew Whitaker points out in the comments below and answers above. Andrew answer is more correct.

A leap year can be defined as divisible by 4 but not divisible by 100 if it is not divisible by 400. Therefore, starting on 1/1/0001 after these rules, there were 488 leap days.

Accounting for these leap days amounted to 735 598 days from 1/1/0001 to the end of 2014. This leaves us with day No. 170 of 2015, which is 6/20/2015 (31 + 28 + 31 + 30 + 31 + 20).

Also, this is not a rounding issue in .NET, as some have suggested. Since DateTime.AddDays uses ticks, which are long data types in the form of 64-bit signed ints, no overflow or rounding occurs.

 Ticks/day = 864BB (or 8.64 x 10^11) Tick / (2,015 years) ~ 1.75 x 10^15 Max long = 9,223,372,036,854,775,807 (or 9.22 x 10^18) 

Answer 3

From the website "It is 735,768 days from the start date to the end date, but not including the end date." This makes me think that you really need to add 735,767 days since the website takes into account the start date. But this will explain only one extra day. Perhaps for one day the site is wrong? They have a warning.

Answer 4

If you run the code below, you may find that in February there are only 28 days 100 200 ... 1900

If you go through the link, you will find 29 days in February for 100,200 .....

http://www.timeanddate.com/calendar/?year=100&country=1

It is better not to compare date.net date with Timeanddate.com.

code:

 static void Main(string[] args) { for (int i = 001; i <= 2015; i++) { if (i % 4 == 0) { if (DateTime.DaysInMonth(i, 2) != 29) { Console.WriteLine("Days {0} in a month feb Year {1}..", DateTime.DaysInMonth(i, 2), i); } } } Console.ReadLine(); } 

Output: -

 Days 28 in a month feb Year 100.. Days 28 in a month feb Year 200.. Days 28 in a month feb Year 300.. Days 28 in a month feb Year 500.. Days 28 in a month feb Year 600.. Days 28 in a month feb Year 700.. Days 28 in a month feb Year 900.. Days 28 in a month feb Year 1000.. Days 28 in a month feb Year 1100.. Days 28 in a month feb Year 1300.. Days 28 in a month feb Year 1400.. Days 28 in a month feb Year 1500.. Days 28 in a month feb Year 1700.. Days 28 in a month feb Year 1800.. Days 28 in a month feb Year 1900.. 

Answer 5

If it were leap years, it would be much more than two days, it would be 503 days off, if that were the case. In my mind, there is one of two options: either that the calculator you use on the network is off a bit, or the math used by C # is inaccurate on this scale. If you do the math yourself, you will see that 735 768/365 reaches a completely irrational number. Therefore, I believe that the inaccuracies in mathematics that go under the hood cannot remain accurate for many days. This happens using decimal points, I assume that C # probably truncates the decimal points (rounding it off), and so you have two days off. My guess is anyway.