Description
given a date argument, datetime can be at best unintuitive, or at worst inaccurate, as opposed to a datetime. If I pass in today's date, depending on the time of day, my results would vary:
$ clj
Clojure 1.12.0
user=> (add-lib 'org.clj-commons/humanize)
[com.widdindustries/cljc.java-time com.widdindustries/cljs.java-time org.clj-commons/humanize]
user=> (require '[clj-commons.humanize :as h])
nil
user=> (h/datetime (java.time.LocalDate/now))
"5 hours ago"
user=>
passing in a date N days in the future, the intuitive result should be "in N days". Instead, I typically get a reply in the form of "in (N-1) days" where one day is dropped off because of the current time:
user=> (h/datetime (.plusDays (java.time.LocalDate/now) 1))
"in 18 hours"
user=> (h/datetime (.plusDays (java.time.LocalDate/now) 3))
"in 2 days"
user=>
Contrast this with how the number reported is as per the intuitive expected result when passing in a date N days in the past:
user=> (h/datetime (.minusDays (java.time.LocalDate/now) 1))
"1 day ago"
user=> (h/datetime (.minusDays (java.time.LocalDate/now) 3))
"3 days ago"
This really comes down to how, at the end of the day, everything is coerced to a datetime before doing the calculation, even if ultimately, I am only thinking in terms of dates / days for the difference (I think that would be the natural interpretation if a date, as opposed to a datetime, is passed in).