Why add days notice period to current date built in function C# not accurate add days correctly?

Question

I working on a C# console app. I face an issue - the built-in add days function does not add days correctly when calculating notice period plus date today. How to solve this issue? Suppose I add 30 days to today's date:

12/01/2024 + 30 = 10/02/2024
12 junuary 2024 + 30 = 10 february 2024 correct result
it give me wrong result as 11 february 2024

but when using the built-in add days function in C#, I get 11/02/2024. Why does it not return the correct result of 10/02/2024 ? Sample code I tried:

// date today returned 12/01/2024
DateTime currentdate = DateTime.Now;

// I add 30 days to 12/01/2024
DateTime lastworkingdate = currentdate.AddDays(30);

// if 3 months then currentdate.AddDays(3 * 30)
// result is 11/02/2024 which is wrong

Expected result is :

10/02/2024

I use sample site online to calculate notice period

https://noticeperiodcalculator.com/

12/01/2024 + 30 = 10/02/2024

Answer 1

Why does it not return the correct result of 10/02/2024 ?

It is probably caused by something like oversight.　Please try the following sample code:

namespace ConsoleApp2
{
    internal class Program
    {
        static void Main(string[] args)
        {
            DateTime date = new DateTime(2024, 12, 1);            
            DateTime date30 = date.AddDays(30);
            DateTime date90 = date.AddDays(3 * 30);

            Console.WriteLine($"2024/12/1: {date}, AddDats(30): {date30}, AddDats(3 * 30): {date90}");
        }
    }
}

The result should be as follows:

Answer 2

The AddDays() method has been around a very long time and it work perfectly. When person refers to the 10th they generally mean all 24 hours within the day. In programming all 24 hours is a timespan which requires a beginning and an ending date/time. To a computer 2024-02-10 starts at midnight where the time is 00:00:00 and ends 24 hours later at 2024-02-11 00:00:00. The AddDays() calculation includes all 24 hours of the 10th and ends the moment the day goes from the 10th to the 11th. The calculation is correct.

I'm guessing the problem is you want to display 2024-02-10 because humans naturally include all 24 hours within the 10th.

A simple solution is to subtract a millisecond from the AddDays results.

DateTime start = new DateTime(2024, 01, 12);
Console.WriteLine(start);
DateTime end = start.AddDays(30).AddMilliseconds(-1);
Console.WriteLine(end);

Answer 3

This issue has nothing to do with milliseconds, or the time part of the date. The simple issue is that this: 12/01/2024 + 30 = 10/02/2024 12

No!!! The above is wrong!

January has 31 days.

You add 1 + 30, the result is 31.

Same goes for this: 12 January 2024 + 30 = 10 February 2024 correct result

No, you get  February 11, NOT the 10th!

Build a test form with a calendar control. Say like this:

And code behind for this form is this:

        private void button1_Click(object sender, EventArgs e)
        {
            DateTime dtStart = monthCalendar1.SelectionStart;
            textBox1.Text = dtStart.AddDays(30).ToString();
        }

        private void button2_Click(object sender, EventArgs e)
        {
            DateTime dtStart = monthCalendar1.SelectionStart;
            textBox2.Text = dtStart.AddMonths(1).ToString();
        }

So, if you have Jan 1st, then adding 30 days gives you Jan 31st! You can't use, nor assume that 30 days = one month (it DOES NOT!!!). As above shows, you can use AddMonths(1), and you get the expected result. So, say this:

So, note above when we select Jan 1st. We add 30 days, we get the 31st! But, when we add ONE month, then we get the 1st of the next month, since AddDays has "knowledge" of the number of days in a month. The same goes for the above when I select Jan 10th. Adding 30 days gives Feb 9, but using AddMonth(1) gives Feb 10. So, all the math and functions are correct, but we are LEAVING OUT that January has 31 days, and not 30 days. We cannot assume, think or write code that assumes 30 days in a month, since as above shows, that simply not the case.