On: Show HN: Durat.io

[strictfp]

Thanks for the QA! I haven't put all to much time into weeding out all the bugs yet. If the site gets popular that will definitely change.

edit: The first bug is a showstopper. Everything is supposed to be a bigint, so this will be fixed ASAP. The second one I will catch and print a nicer error for. The third one I will have to look into. I probably perform the calculation incorrectly by using the wrong temporal types. Thanks again.

[JoshTriplett → strictfp]

The third one is the hardest to deal with:

  ~$ cal 9 1752
     September 1752     
  Su Mo Tu We Th Fr Sa  
         1  2 14 15 16  
  17 18 19 20 21 22 23  
  24 25 26 27 28 29 30  

This isn't the only bit of craziness you'd need to deal with if you wanted to handle historical times perfectly. For instance, consider attempting to get an accurate duration in hours of a time that extends across the daylight savings time switchover, historically, in a region where that has changed from year to year.

Another interesting one: 2015-07-01 - 2015-06-29 returns "PT48H", but it should be 48 hours and 1 second.

[strictfp → JoshTriplett]

I'm currently passing on all the date calculations to the java.time API, so at least I won't have to do it all on my own. But it's sometimes a challenge to even pass it down the right way will all the different use-cases and temporal types available.