3 ms·

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/

by avip 7y ago

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_datetime.py 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.

karlp 7y ago
For date and time, Arrow is a lifesaver in python https://arrow.readthedocs.io/en/latest/ https://arrow.readthedocs.io/en/latest/
nkozyra 7y ago
> I once stupidly implemented a "date math" feature I believe this to be one of those rites of passage for any programmer.
- WorldMaker 7y ago
  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 7y ago
    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 7y ago
      > Convert to seconds_since_the_epoch immediately. oh my sweet summer child

by avip 7y ago

karlp 7y ago

For date and time, Arrow is a lifesaver in python https://arrow.readthedocs.io/en/latest/ https://arrow.readthedocs.io/en/latest/

nkozyra 7y ago

> I once stupidly implemented a "date math" feature I believe this to be one of those rites of passage for any programmer.

WorldMaker 7y ago
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 7y ago
  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 7y ago
    > Convert to seconds_since_the_epoch immediately. oh my sweet summer child