For example, using nice_duration to check how long it's been since a datetime in early July of 2016 produced, "eleven sixty six days five hours one second."
If you just ask Mycroft that question, it kicks over to Wolfram, which produces the desired output. I realize that it's a nightmarish task trying to tackle days to years, given leap years and all, but I reckon it should at least move to hundreds: "eleven hundred sixty six days..." (or "one thousand one hundred sixty six days")
Thanks for reporting this :)
If anyone is keen to tackle it and wants to handle leap years, I used the following in the Date-Time Skill recently:
def is_leap_year(self, year):
return (year % 400 == 0) or ((year % 4 == 0) and (year % 100 != 0))
There's also the calendar.isleap
function in the standard library...
The humanize module might be something to look at as well...
>>> humanize.naturaldelta(timedelta(minutes=40, hours=360000))
'41 years'
If somebody _is_ going to refactor this function, it might be worth giving the thing resolution while they're in there. It's amusing and 100% in character for Mycroft to tell you how many seconds have passed since that day long ago, but coders might prefer to specify, nice_duration_years()
or nice_duration(dt1, dt2, <str>resolution)
Yeah I've been thinking about "resolution" for a number of these functions but don't want to make breaking changes. Seems like that could be less of an issue here if we only add an optional parameter and it still just returns a string, eg:
nice_duration(<int>seconds, <str>resolution)
Because I'm not coding this myself, I'll make a thousand suggestions!
If these functions do get resolution, perhaps years could operate over trimesters, or consider how many months or etc. make the difference between "about 2 years," "almost 2 years," "a little over 2 years," or just "2 years"
I just started fussing with this in the interpreter, and I don't think it'll be as hard as I thought. If nobody else has started yet, I'll do it after dinner.
Fix merged.