That and/or "rip out this idiot date math library written by your predecessor and try to use an industry standard library instead". Especially the karma of first one then the other.
About the only way to keep your sanity is to treat dates in only one of two ways, depending on the context:
1. As a string you don't touch
2. Convert to seconds_since_the_epoch immediately. Convert back only when necessary (when printing to the screen or sending to a SQL query for example).
This calc problem is somewhat unique because months and years aren't fixed length and it's probably bad if your program says Feb 1 to March 1 is less than a month, or Jan 1 2000 to Jan 1 2001 is a year and a day. Or if Jan 1 2001 to Jan 1 2002 is a year and a quarter of a day. And then you have to account for those occasional years that are divisible by 4 but are not a leap year. And then you have to account for when someone asks for the difference between September 1 1752 and September 20 1752. Pretty soon you're remembering why rules 1 and 2 exist. It should be noted that calc.exe gets this wrong in many ways.
1. As a string you don't touch
2. Convert to seconds_since_the_epoch immediately. Convert back only when necessary (when printing to the screen or sending to a SQL query for example).
This calc problem is somewhat unique because months and years aren't fixed length and it's probably bad if your program says Feb 1 to March 1 is less than a month, or Jan 1 2000 to Jan 1 2001 is a year and a day. Or if Jan 1 2001 to Jan 1 2002 is a year and a quarter of a day. And then you have to account for those occasional years that are divisible by 4 but are not a leap year. And then you have to account for when someone asks for the difference between September 1 1752 and September 20 1752. Pretty soon you're remembering why rules 1 and 2 exist. It should be noted that calc.exe gets this wrong in many ways.