[avip]

I once stupidly implemented a "date math" feature, and after introducing numerous bugs in production opted to use https://svn.python.org/projects/sandbox/trunk/datetime/test_... as my ref. test (which exposed numerous other bugs). Likely not full coverage of all date-time related bizarrities, yet a useful resource.

[nkozyra]

> I once stupidly implemented a "date math" feature

I believe this to be one of those rites of passage for any programmer.

[WorldMaker]

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.

[jandrese]

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.

[techslave]

> Convert to seconds_since_the_epoch immediately.

oh my sweet summer child

[karlp]

For date and time, Arrow is a lifesaver in python

https://arrow.readthedocs.io/en/latest/