How to get difference between two dates in Year/Month/Week/Day?

Question

How to get difference between two dates in Year/Month/Week/Day in an efficient way?

eg. difference between two dates is 1 Year, 2 Months, 3 Weeks, 4 Days.

Difference represents count of year(s), month(s), week(s) and day(s) between two dates.

Answer 1

This is actually quite tricky. A different total number of days can result in the same result. For example:

• 19th June 2008 to 19th June 2010 = 2 years, but also 365 * 2 days

• 19th June 2006 to 19th June 2008 = 2 years, but also 365 + 366 days due to leap years

You may well want to subtract years until you get to the point where you've got two dates which are less than a year apart. Then subtract months until you get to the point where you've got two dates which are less than a month apart.

Further confusion: subtracting (or adding) months is tricky when you might start with a date of "30th March" - what's a month earlier than that?

Even further confusion (may not be relevant): even a day isn't always 24 hours. Daylight saving anyone?

Even further confusion (almost certainly not relevant): even a minute isn't always 60 seconds. Leap seconds are highly confusing...

I don't have the time to work out the exact right way of doing this right now - this answer is mostly to raise the fact that it's not nearly as simple as it might sound.

EDIT: Unfortunately I'm not going to have enough time to answer this fully. I would suggest you start off by defining a struct representing a Period:

public struct Period {     private readonly int days;     public int Days { get { return days; } }     private readonly int months;     public int Months { get { return months; } }     private readonly int years;     public int Years { get { return years; } }      public Period(int years, int months, int days)     {         this.years = years;         this.months = months;         this.days = days;     }      public Period WithDays(int newDays)     {         return new Period(years, months, newDays);     }      public Period WithMonths(int newMonths)     {         return new Period(years, newMonths, days);     }      public Period WithYears(int newYears)     {         return new Period(newYears, months, days);     }      public static DateTime operator +(DateTime date, Period period)     {         // TODO: Implement this!     }      public static Period Difference(DateTime first, DateTime second)     {         // TODO: Implement this!     } } 

I suggest you implement the + operator first, which should inform the Difference method - you should make sure that first + (Period.Difference(first, second)) == second for all first/second values.

Start with writing a whole slew of unit tests - initially "easy" cases, then move on to tricky ones involving leap years. I know the normal approach is to write one test at a time, but I'd personally brainstorm a bunch of them before you start any implementation work.

Allow yourself a day to implement this properly. It's tricky stuff.

Note that I've omitted weeks here - that value at least is easy, because it's always 7 days. So given a (positive) period, you'd have:

int years = period.Years; int months = period.Months; int weeks = period.Days / 7; int daysWithinWeek = period.Days % 7; 

(I suggest you avoid even thinking about negative periods - make sure everything is positive, all the time.)

Answer 2

Partly as a preparation for trying to answer this question correctly (and maybe even definitively...), partly to examine how much one can trust code that is pasted on SO, and partly as an exercise in finding bugs, I created a bunch of unit tests for this question, and applied them to many proposed solutions from this page and a couple of duplicates.

The results are conclusive: not a single one of the code contributions accurately answers the question. Update: I now have four correct solutions to this question, including my own, see updates below.

Code tested

From this question, I tested code by the following users: Mohammed Ijas Nasirudeen, ruffin, Malu MN, Dave, pk., Jani, lc.

These were all the answers which provided all three of years, months, and days in their code. Note that two of these, Dave and Jani, gave the total number of days and months, rather than the total number of months left after counting the years, and the total number of days left after counting the months. I think the answers are wrong in terms of what the OP seemed to want, but the unit tests obviously don't tell you much in these cases. (Note that in Jani's case this was my error and his code was actually correct - see Update 4 below)

The answers by Jon Skeet, Aghasoleimani, Mukesh Kumar, Richard, Colin, sheir, just i saw, Chalkey and Andy, were incomplete. This doesn't mean that the answers weren't any good, in fact several of them are useful contributions towards a solution. It just means that there wasn't code taking two DateTimes and returning 3 ints that I could properly test. Four of these do however talk about using TimeSpan. As many people have mentioned, TimeSpan doesn't return counts of anything larger than days.

The other answers I tested were from

• question 3054715 - LukeH, ho1 and this. ___curious_geek
• question 6260372 - Chuck Rostance and Jani (same answer as this question)
• question 9 (!) - Dylan Hayes, Jon and Rajeshwaran S P

this.___curious_geek's answer is code on a page he linked to, which I don't think he wrote. Jani's answer is the only one which uses an external library, Time Period Library for .Net.

All other answers on all these questions seemed to be incomplete. Question 9 is about age in years, and the three answers are ones which exceeded the brief and calculated years, months and days. If anyone finds further duplicates of this question please let me know.

How I tested

Quite simply: I made an interface

public interface IDateDifference {   void SetDates(DateTime start, DateTime end);   int GetYears();   int GetMonths();   int GetDays();  } 

For each answer I wrote a class implementing this interface, using the copied and pasted code as a basis. Of course I had to adapt functions with different signatures etc, but I tried to make the minimal edits to do so, preserving all the logic code.

I wrote a bunch of NUnit tests in an abstract generic class

[TestFixture] public abstract class DateDifferenceTests<DDC> where DDC : IDateDifference, new() 

and added an empty derived class

public class Rajeshwaran_S_P_Test : DateDifferenceTests<Rajeshwaran_S_P> { } 

to the source file for each IDateDifference class.

NUnit is clever enough to do the rest.

The tests

A couple of these were written in advance and the rest were written to try and break seemingly working implementations.

[TestFixture] public abstract class DateDifferenceTests<DDC> where DDC : IDateDifference, new() {   protected IDateDifference ddClass;    [SetUp]   public void Init()   {     ddClass = new DDC();   }    [Test]   public void BasicTest()   {     ddClass.SetDates(new DateTime(2012, 12, 1), new DateTime(2012, 12, 25));     CheckResults(0, 0, 24);   }    [Test]   public void AlmostTwoYearsTest()   {     ddClass.SetDates(new DateTime(2010, 8, 29), new DateTime(2012, 8, 14));     CheckResults(1, 11, 16);   }    [Test]   public void AlmostThreeYearsTest()   {     ddClass.SetDates(new DateTime(2009, 7, 29), new DateTime(2012, 7, 14));     CheckResults(2, 11, 15);   }    [Test]   public void BornOnALeapYearTest()   {     ddClass.SetDates(new DateTime(2008, 2, 29), new DateTime(2009, 2, 28));     CheckControversialResults(0, 11, 30, 1, 0, 0);   }    [Test]   public void BornOnALeapYearTest2()   {     ddClass.SetDates(new DateTime(2008, 2, 29), new DateTime(2009, 3, 1));     CheckControversialResults(1, 0, 0, 1, 0, 1);   }     [Test]   public void LongMonthToLongMonth()   {     ddClass.SetDates(new DateTime(2010, 1, 31), new DateTime(2010, 3, 31));     CheckResults(0, 2, 0);   }    [Test]   public void LongMonthToLongMonthPenultimateDay()   {     ddClass.SetDates(new DateTime(2009, 1, 31), new DateTime(2009, 3, 30));     CheckResults(0, 1, 30);   }    [Test]   public void LongMonthToShortMonth()   {     ddClass.SetDates(new DateTime(2009, 8, 31), new DateTime(2009, 9, 30));     CheckControversialResults(0, 1, 0, 0, 0, 30);   }    [Test]   public void LongMonthToPartWayThruShortMonth()   {     ddClass.SetDates(new DateTime(2009, 8, 31), new DateTime(2009, 9, 10));     CheckResults(0, 0, 10);   }    private void CheckResults(int years, int months, int days)   {     Assert.AreEqual(years, ddClass.GetYears());     Assert.AreEqual(months, ddClass.GetMonths());     Assert.AreEqual(days, ddClass.GetDays());   }    private void CheckControversialResults(int years, int months, int days,     int yearsAlt, int monthsAlt, int daysAlt)   {     // gives the right output but unhelpful messages     bool success = ((ddClass.GetYears() == years                      && ddClass.GetMonths() == months                      && ddClass.GetDays() == days)                     ||                     (ddClass.GetYears() == yearsAlt                      && ddClass.GetMonths() == monthsAlt                      && ddClass.GetDays() == daysAlt));      Assert.IsTrue(success);   } } 

Most of the names are slightly silly and don't really explain why code might fail the test, however looking at the two dates and the answer(s) should be enough to understand the test.

There are two functions that do all the Asserts, CheckResults() and CheckControversialResults(). These work well to save typing and give the right results, but unfortunately they make it harder to see exactly what went wrong (because the Assert in CheckControversialResults() will fail with "Expected true", rather than telling you which value was incorrect. If anyone has a better way to do this (avoid writing the same checks each time, but have more useful error messages) please let me know.

CheckControversialResults() is used for a couple of cases where there seem to be two different opinions on what is right. I have an opinion of my own, but I thought I should be liberal in what I accepted here. The gist of this is deciding whether one year after Feb 29 is Feb 28 or Mar 1.

These tests are the crux of the matter, and there could very well be errors in them, so please do comment if you find one which is wrong. It would be also good to hear some suggestions for other tests to check any future iterations of answers.

No test involves time of day - all DateTimes are at midnight. Including times, as long as it's clear how rounding up and down to days works (I think it is), might show up even more flaws.

The results

The complete scoreboard of results is as follows:

ChuckRostance_Test 3 failures               S S S F S S F S F Dave_Test 6 failures                        F F S F F F F S S Dylan_Hayes_Test 9 failures                 F F F F F F F F F ho1_Test 3 failures                         F F S S S S F S S Jani_Test 6 failures                        F F S F F F F S S Jon_Test 1 failure                          S S S S S S F S S lc_Test 2 failures                          S S S S S F F S S LukeH_Test 1 failure                        S S S S S S F S S Malu_MN_Test 1 failure                      S S S S S S S F S Mohammed_Ijas_Nasirudeen_Test 2 failures    F S S F S S S S S pk_Test 6 failures                          F F F S S F F F S Rajeshwaran_S_P_Test 7 failures             F F S F F S F F F ruffin_Test 3 failures                      F S S F S S F S S this_curious_geek_Test 2 failures           F S S F S S S S S 

But note that Jani's solution was actually correct and passed all tests - see update 4 below.

The columns are in alphabetical order of test name:

• AlmostThreeYearsTest
• AlmostTwoYearsTest
• BasicTest
• BornOnALeapYearTest
• BornOnALeapYearTest2
• LongMonthToLongMonth
• LongMonthToLongMonthPenultimateDay
• LongMonthToPartWayThruShortMonth
• LongMonthToShortMonth

Three answers failed only 1 test each, Jon's, LukeH's and Manu MN's. Bear in mind these tests were probably written specifically to address flaws in those answers.

Every test was passed by at least one piece of code, which is slightly reassuring that none of the tests are erroneous.

Some answers failed a lot of tests. I hope no-one feels this is a condemnation of that poster's efforts. Firstly the number of successes is fairly arbitrary as the tests don't evenly cover the problem areas of the question space. Secondly this is not production code - answers are posted so people can learn from them, not copy them exactly into their programs. Code which fails a lot of tests can still have great ideas in it. At least one piece which failed a lot of tests had a small bug in it which I didn't fix. I'm grateful to anyone who took the time to share their work with everyone else, for making this project so interesting.

My conclusions

There are three:

1. Calendars are hard. I wrote nine tests, including three where two answers are possible. Some of the tests where I only had one answer might not be unanimously agreed with. Just thinking about exactly what we mean when we say '1 month later' or '2 years earlier' is tricky in a lot of situations. And none of this code had to deal with all the complexities of things like working out when leap years are. All of it uses library code to handle dates. If you imagine the 'spec' for telling time in days, weeks, months and years written out, there's all sorts of cruft. Because we know it pretty well since primary school, and use it everyday, we are blind to many of the idiosyncracies. The question is not an academic one - various types of decomposition of time periods into years, quarters and months are essential in accounting software for bonds and other financial products.

2. Writing correct code is hard. There were a lot of bugs. In slightly more obscure topics or less popular questions than the chances of a bug existing without having been pointed out by a commenter are much, much higher than for this question. You should really never, never copy code from SO into your program without understanding exactly what it does. The flipside of this is that you probably shouldn't write code in your answer that is ready to be copied and pasted, but rather intelligent and expressive pseudo-code that allows someone to understand the solution and implement their own version (with their own bugs!)

3. Unit tests are helpful. I am still meaning to post my own solution to this when I get round to it (for someone else to find the hidden, incorrect assumptions in!) Doing this was a great example of 'saving the bugs' by turning them into unit tests to fix the next version of the code with.

Update

The whole project is now at https://github.com/jwg4/date-difference This includes my own attempt jwg.cs, which passes all the tests I currently have, including a few new ones which check for proper time of day handling. Feel free to add either more tests to break this and other implementations or better code for answering the question.

Update 2

@MattJohnson has added an implementation which uses Jon Skeet's NodaTime. It passes all the current tests.

Update 3

@KirkWoll's answer to Difference in months between two dates has been added to the project on github. It passes all the current tests.

Update 4

@Jani pointed out in a comment that I had used his code wrongly. He did suggest methods that counted the years, months and days correctly, (alongside some which count the total number of days and months, not the remainders) however I mistakenly used the wrong ones in my test code. I have corrected my wrapper around his code and it now passes all tests. There are now four correct solutions, of which Jani's was the first. Two use libraries (Intenso.TimePeriod and NodaTime) and two are written from scratch.