Datetime.Adddays() Not Working as Expected

DateTime.AddDays() not working as expected

It does work but you don't do anything with the return value, try

aux2 = aux2.AddDays(1);

DateTimes share this facet of immutability with Strings.

---

EDIT

There is a little paragraph about it on MSDN

This method does not change the value of this DateTime. Instead, it
returns a new DateTime whose value is the result of this operation.

AddDays() not working within a while loop

The reason being is that DateTime is Immutable, this means that you can't directly modify it and instead need to create a new instance of it. Strings are another type that behave in this way which you may be more used to.

first_day = first_day.AddDays(1);

C# DateTime AddDays Unexpected Offset

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

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

• The formula for leap years on the Julian Calendar is "every year divisible by 4". This means that there are way more leap years in timeanddate.com's calculation between year 1 and year 1752, when the Calendar changes. This puts .NET's calculations until 1753 behind by 11 days.
• Until 1752, England and the east coast of the United States used the Julian Calendar. A consequence of this change is that 1752 was only 355 days long. This calculation is not taken into account by .NET's calculation, and so at this point, .NET's calculation is two days ahead.

According to this answer by Jon Skeet, DateTime essentially uses the Gregorian calendar exclusively. This is why the above subtleties aren't reflected in .NET's calculations.

How Accurate is DateTime.AddDays?

As DateTime stores the date internaly as 64 bit integer where one tick represents 100 nanoseconds, there is no risk of an error. One day has 864,000,000,000 ticks and Double has a precision of at least 15 digits. So every error is vanished when rounding to ticks because Double has a higher resolution than one tick if 1.0 equals one day.

This would not be true for AddYears(), because Double has not enough precision to represent one tick if 1.0 equals one year. But if you look at the DateTime class, you see that the design respects that fact - AddMonths() and AddYears() have both integer and not floating point arguments.

To check this just execute the following code.

DateTime now = DateTime.Now;

// Displays 864000000000 
Console.WriteLine(now.AddDays(1.0).Ticks - now.Ticks);

Filtering in DataTable is not working for DateTime.Now or DateTime.AddDays

The row filter for date/time values handles sub second components (milliseconds...).

But the default format for date/time does not include these.

Your filter will only work when date1 and date2 don't have sub second components which is the case in your first code snippet (this DateTime constructor sets them to 0).

One solution is to give ToString a format that does include the sub second components.

C# DateTime AddDays off by one

Lets take these days one at a time for illustration...

3rd - 1 = 2nd

2nd - 1 = 1st

1st - 1 = 30th

30th - 1 = 29th

There is no zero day in months as with "normal" numbers.

DateTime.AddDays what value to pass to generate an exception

If you pass in int.MaxValue, that should end up with a value which is outside the representable range for DateTime, whatever the original DateTime is.

Sample code, tested on csharppad.com:

DateTime.MinValue.AddDays(int.MaxValue);

Using Assert.Fail in a finally block is a mistake though... that will always be called. It's not clear what your test framework is, but I'd expect something like:

Assert.Throws<ArgumentOutOfRangeException>(() => /* code here */);

C# Not adding a year with .AddYears(1);

DateTime values are immutable. AddYears does not modify the current instance, but instead returns a new one.

That means you should do:

nu = nu.AddYears(18);

Does calling DateTime.AddDays with a whole number always leave the time unchanged?

1. DateTime does not account for leap seconds. You can read this article from which you will see that because of this it doesn't really support UTC. Documentation states that:

Time values are measured in 100-nanosecond units called ticks, and a
particular date is the number of ticks since 12:00 midnight, January
1, 0001 A.D. (C.E.) in the GregorianCalendar calendar (excluding ticks
that would be added by leap seconds)

2. About daylight saving time documentation states the following:

Conversion operations between time zones (such as between UTC and
local time, or between one time zone and another) take daylight saving
time into account, but arithmetic and comparison operations do not.

That means that adding days (which is arithmetic operation) to DateTime instance, even if it has kind Local (so represents time in local timezone) does not take DST into account. That makes performing any arithmetic operations on datetimes with kind Local a really bad idea. If you need to do that with date times - first convert it to UTC (that has no notion of DST), perform operation then convert back to local (conversion as stated above does take DST into account).

You can also look at source code to see that datetime value is stored as a number internally (number of ticks) and adding days just adds fixed value to that number. Calculating hour\minute\second use that value and perform fixed operations (just a division) to obtain target value. None of those operations account for anything like leap seconds, time zones or anything else. So the answer to your question is yes.

while loop returning same date value even after adding a day each time - c#

you need to assign to fromDate, AddDays() does not modify the instance on which it is called:

fromDate = fromDate.AddDays(1);

---

Related Topics