Requirements:
Calculate the number of months
between two dates: receiveDate and
dueDate.
Both optimistic and pessimistic
calculations are needed
Assumptions:
dueDate will always be the last day of the month.
I've already figured out the pessimistic calculation (meaning a single day overdue counts as a whole month:
if(receiveDate > dueDate)
receiveDate.Month - dueDate.Month + (receiveDate.Year - dueDate.Year) * 12;
Doing a search on the internet turned up several similar examples to confirm this.
Now my instincts tell me the optimistic calculation will just be the same minus one month but for some reason it just doesn't feel right. Am I on the right track or am I missing something?
You're right; if you're looking for the number of complete months between the two dates, subtracting 1 (assuming the receiveDate doesn't fall on the last day of the month, in which case you will have a remainder of 0 days either way) will get you your answer.
If you don't need to keep days of month in your calculus I think it's the way to go.
Your formula calculates the number of months between the first of the receivedDate's month to the first of the dueDate's month. As most time elements in TimeSpan are expressed as TotalXXX, it seems weird that they left out a TotalMonths and a TotalYears.
I think it's because there aren't a fixed number of days from month to month, so it's hard to know what makes most sense in terms of how to express the fractional remainder.
My formula is this...
int nMonthDiff_FirstToFirst = DateTime.Now.Month - testDate.Month + ((DateTime.Now.Year - testDate.Year)* 12);
double dMonthDiff = (double)nMonthDiff_FirstToFirst + (DateTime.Now - testDate.AddMonths(nMonthDiff_FirstToFirst)).TotalDays / (double)DateTime.DaysInMonth(DateTime.Now.Year, DateTime.Now.Month);
So what I'm doing is basically getting the month difference like you are (first of the month to first of the month) then I project my testDate into the future by the month difference. Then with that TimeSpan I get the TotalDays and divide that by the number of days in that month. Thus I'm representing the fractional portion in terms of remaining days of the month.
So if you were going May 5st 2012 -> June 3rd 2012, your formula would return 1 for month difference when a full month hasn't passed yet. In my formula the TotalDays of the projected date would yield a negative fractional number of days, and when added to the 'first to first' month difference, it would take it in as needed.
I am doing this extra check to get precise amount of months:
numberOfMonths = receiveDate.Month - dueDate.Month + (receiveDate.Year - dueDate.Year) * 12;
if (receiveDate.Day > dueDate.Day) numberOfMonths--;
int GetMonthsCount(DateTime dtStart, DateTime dtEnd)
{
return (int)Math.Round((dtEnd - dtStart).TotalMonths);
}
Related
I have a unit test where the expected result is a DateTime and is set as follows:
var expectedResult = DateTime.Today.AddMonths(3).AddMonths(3);
After which I have a function that adds quarters to a date:
DateTime.AddMonths(3 * numberOfTimes);
numberOfTimes is in this case 2.
The results differ in date. Today is 31/01/2023, expected result is 30/07/2023 and the function result is 31/07/2023.
I expected the results to be the same because 6 months should have been equal number of days from the starting date. I am curious why this happens. For now I fixed the problem by doing 3 * numberOfTimes in the expectedResult section.
Just out of curiosity why does this happen?
It is documented:
The AddMonths method calculates the resulting month and year, taking
into account leap years and the number of days in a month, then
adjusts the day part of the resulting DateTime object. If the
resulting day is not a valid day in the resulting month, the last
valid day of the resulting month is used. For example, March 31st + 1
month = April 30th, and March 31st - 1 month = February 28 for a
non-leap year and February 29 for a leap year.
So you get a different result because if you add 6 months it just needs to be checked if 31/07/2023 is a valid DateTime, which it is. For DateTime.Today.AddMonths(3).AddMonths(3) it will check first if 31/04/2023 is valid, which is not, so 30/04/2023 is returned, then 3 months are added.
The result can be different because of the way that the date and time is calculated for each method. The DateTime.AddMonths method takes into account the number of days in each month and can result in a different day of the month if the original date has a different number of days in the month. For example, adding 3 months to January 31st would result in a different day of the month than adding 6 months to January 31st.
This code lets you calulate the difference in months between two dates, Date2 > Date1
public int MonthDiff(DateTime Date1, DateTime Date2)
{
return Math.Abs((Date2.Month - Date1.Month) + 12 * (Date2.Year - Date1.Year));
}
In my example if I put Date1 = "01/01/2019" & Date2 = "31/12/2019", it will return 11, and this is wrong, it should be 12.
Also if I put Date1 = "25/01/2019" & Date = "31/12/2019", it should be 12.
So the question should I need to calculate by Days or what?
I used this code
return Math.Abs(((Date2- Date1).Days / 30) + 12 * (Date2.Year - Date1.Year));
With Date1 = "01/01/2019" & Date2 = "31/12/2020", it shows 36 Months.
If you want to know the difference between two dates in variable length units like months or years, you should use the built in timespan functionality rather than roll your own, and accept some compromises/approximations. The average number of days in a year is 365.2425. The average number of days in a month is 30.42 for a non leap year or 30.50 for a leap year, or 30.44 overall. Choose one of these values when approximating the months. Choose whether to round down, or round up, and to how many decimal places when working out the months/years
For example:
var a = DateTime.Now;
var b = DateTime.Now.AddDays(366);
var years = Math.Round((b-a).TotalDays/365.2425);
You could take some alternative approaches like:
have an array of integers that depict the number of days in each month (over a four year period so leap February are accounted for) and a logic of "I will get the number of days between the two dates, then I will consider the month of the start date and set an array indexer variable pointing to that month in the a"rray-of-month-lengths", and I will subtract the number of days in that month from my total, then I'll move on to the next index in the array (going back to the array start if necessary) and subtract that.. and I'll keep doing it until the remaining total days is lower than the number of days in whatever month I'm looking at.. and the number of times I looped shall be the result of the number of months between the day"
write a loop that adds one day to the start date until the end date is breached, and count how many times the current month number is different to the month number on the last iteration of the loop
etc
These are decisions to implement very specific sorts of approximations
I don't think there is a good fact based answer to your question until you accurately explain every rule you want your math you work to, so all the exceptions can be coded for. Saying "x - y is 11 months and this is wrong" is not a rule; you need to say why it is wrong
I have a very simple DateTime object that is set to the date 01-01-0001. I am supplied a value to add to this DateTime, in days. I am seeing an unexpected offset in my results though, of two days. Let's pretend I print out the results of the AddDays() call, like so:
DateTime myDateTime = DateTime.Parse("01-01-0001 00:00:00");
Console.WriteLine(myDateTime.AddDays(735768.0));
With the value seen above (735768.0) I expect an output of "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 there something going on under the hood that I am not aware of?
In case you are wondering, the 735,768 represents the first time value of the data that I am working with. The data is expected to start at 06/18/2015 00:00:00.
Edit: I should note I merely provided that particular website as an example of a conflicting source. Other websites, including the government weather agency I get the data from all give me 06-18-2015. This doesn't mean C# is wrong. I am more so curious as to where this offset came from, and why.
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.
.NET is giving you the "correct" answer - noting that "correct" is assuming a purely gregorian calendar as Andrew Whitaker points out in the comments below and answer above. Andrew's answer is more correct.
A leap year can be defined as divisible by 4, but not divisible by 100 unless it is divisible by 400. Therefore, since 1/1/0001 following those rules, there have been 488 leap days.
Accounting for these leap days, there have been 735,598 days from 1/1/0001 through end of 2014. This leaves us to find day #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 as 64-bit signed ints, no overflows or rounding is occurring.
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)
From the website "It is 735,768 days from the start date to the end date, but not including the end date". This leads me to think, that you actually need to add 735,767 days since the website counts the start date. But this will only explain the one extra day. Perhaps the website is wrong by one day ? They do have a warning.
If you run below code you can find there are only 28 days in Feb for years
100,200 ...... 1900
IF you go through link you will find 29days in Feb for years 100,200....
http://www.timeanddate.com/calendar/?year=100&country=1
Its better not to compare .net date day to 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..
If it were leap years it would be a lot more than 2 days, it would be 503 days off if that were the case. There's one of two options in my mind, either A. that calculator you are using online is off a little bit off, or the math that C# is using is inaccurate at that scale. If you do the math yourself you'll see that 735,768 / 365 comes out to a totally irrational number. So my thinking is that the inaccuracies in the math that goes on under the hood can't stay accurate for that many days. This happens ALOT with decimal points, I assume C# is probably truncating the decimal points (rounding it down) and so you're two days off. My guess anyway.
I'm writing a search program that includes a date range- DateFrom and DateTo, both of which are DateTimes. Searching January - April for any search criteria will return the results of January + February + March + April.
I would like to add functionality whereby a user can choose to search each month within a - range, so searching January - April will return each individual month's results. However I'm having trouble finding an intelligent way to implement this for any unit of time larger than days.
So far I'm getting a TimeSpan using:
TimeSpan ts = query.DateTo - query.DateFrom;
In a perfect world I'd just be able to do something like foreach (month m in TimeSpan){dostuff}, however TimeSpan stores dates as integers and does not include any units larger than days. Additionally, I thought maybe I could just use n = DateFrom.month - DateTo.month to get the difference in months and run a function in a for loop starting with DateFrom and lasting n months, but this won't work between years.
The last case is definitely fixable but includes a number of tedious special cases. Is there a cleaner / more elegant way of accomplishing this sort of iteration that I'm missing?
Thanks.
So for the basic pattern we can use a fairly simple for loop:
public static IEnumerable<DateTime> Months(DateTime start, DateTime end)
{
for (DateTime date = start; date < end; date = date.AddMonths(1))
yield return date;
}
Now in this case we have a start date that is inclusive and an end date that is exclusive. If we want to make the end date inclusive, as you have described, we can add:
end = end.AddMonths(1);
to the start of the method.
Next you have a few other considerations. Are the datetime objects passed in going to always be the first of the month? If not, how do you want to support it? If the start date is Feb 10th do you want the first yielded date to be Feb 1st (the start of the start date's month), March 1st (the first "first day of the month" on or after the start date), or Feb 10th (meaning that each date in the timespan would be the 10th day of that month)?
Those same questions also apply to the end date; do you want the last "first day of the month" before the end date, the first day of the next month, etc.
Also, what should happen if the start date is after the end date? Should it yield the dates "backwards", should it just pretend the start date is the end date and the end date is the start date? Should it keep adding days until you've overflowed DateTime and come back around to that date?
Pretty much all of these issues aren't too hard to deal with, the hard part is just knowing what you want to do in each case.
You could do something like:
var months = ((query.DateTo.Year - query.DateFrom.Year) * 12) + query.DateTo.Month - query.DateFrom.Month
for(int i=0;i<months;i++){
//do stuff as below
var currentDate=query.DateFrom.AddMonths(i);
}
I have the following LINQ Query:
model.TotalEnquiries = enquiriesDbContext.Enquiries.Where(x => x.CustomerAccountNumber == formModel.CustomerAccNo)
.Where(x => x.EnquiryDate >= startDate).Where(x => x.EnquiryDate <= endDate).Count();
This works fine as it'll return a value of say, 60, between 2 specified time periods, but what I'd like to do is find the average number of enquiries per day, week and month for this period, is it possible in LINQ?
Well given that you've specified the period yourself, it's easy:
var averagePerDay = total / (endDate - startDate).TotalDays;
EDIT: I see you're changing the goalposts... if you want to get averages for different date ranges in one query then it's going to be tricky. Personally, unless there's a huge amount of data, I'd probably fetch all the enquiry dates within the appropriate range, and then process it locally, which is likely to be easier than trying to minimize the number of SQL queries while still keeping them smart.
Averaging by month over an arbitrary period is conceptually tricky: how many months are in the period of (say) February 16th to April 7th? Three different month lengths are involved.
Of course, you may mean "average by day, grouping by month" (e.g. average by day in January, average by day in February" etc) which is entirely different. This is why you need to be precise about requirements.
You need to use a GROUP BY to group the entries by day, documented here (with samples)
Otherwise you'll need to settle for doing an average via SUM/COUNT which gives you less insight into the distribution, trends, etc.