Forums Feature Suggestions $duration years? months?

Why does $duration stop as weeks?

I understand that it's a question of where you stop, but years and months are a recognised standard.

I'd be interested to know why it only does up to weeks, and if any consideration has been given to adding years and months.

Because the length of a month varies depending on which it is? Averaging at 30 days or any other number would just make $duration lose accuracy...

As mentioned, months/years requires taking into account variable month length and leap years. There are some identifiers made to handle displaying months/years correctly, however. I made up $DateXpander (available from mircscripts.org) and someone here made up $datediff. Sorry, I forget who did that one and where it's downloadable from.

Both take into account the variable months and leap years and let you display months and years correctly.

I remember Mpdreamz making $datediff. I think it's available on mircscripts.org if I remember rightly.

Well really years are just 365.4 days, and so months are 30.45 days each.

Really you'd think there was an option to guestimate that.

ie: I can't comprehend 227wks... where as 4.3 years, I can.

Anything is be better than nothing...

Actually, years are 365.2425 days long.

-genius_at_work

Ah yes...

http://www.google.com/search?q=year+to+days

1 year = 365.242199 days

I can only assume I actually meant 365 and 1/4 or 365.25... my school physics lessons are slowly coming back to me :p

If $duration "guessed" the duration, it wouldn't be very good. And if you are displaying weeks and days as well, how do you get that decimal working correctly in the display?

For example, Feb 1 to March 1 on a non-leap year is 28 days. It's also 1 month. If you calculate months as 30.45 days or whatever, then it will not display as 1 month, even though it is. Obviously, once you have 100 weeks duration, a day or two here or there isn't a big deal (in most cases), but $duration is used for short durations AND long durations and having it be really wrong on short durations just so long durations look nicer isn't very good.

I've never looked at the coding in $datediff, but for $DateXpander, it uses the current month/year (or whatever month/year is chosen) and determines the exact number of days/months based on how many days/weeks/months/years there really are in the month/year. Try both out and see what you think. You can even use basically the same format for $DateXpander as $duration as long as you're doing a duration from the current date into the past (such as a !seen script). If you want to go into the future (a countdown) or have the duration at some other set of dates rather than from the current date, the format changes some, but it handles it just fine.

$duration includes a 2nd parameter anyways, which specifies whether we want seconds, or a hh:nn:ss format.
I don't see a problem if Khaled would include a switch that specifies "years please, i don't care if its only an estimate!" - infact, for durations > 6 months you wont possibly notice a day or two missing, especially not for years.

That's what a custom identifier is for and why there are at least 2 available for anyone who wants them. There's no reason to offer an inaccurate output from $duration.

I agree, adding a purposely inaccurate output is just inviting bug reports as soon as it's released - or else causing someone problems when it returns a result they don't know is wrong. And dividing by a year length of 365.2425 just causes the year to rollover at crazy times during the day.

For example, I don't know if it's changed since Excel 2000, but it had a function 'yearfrac' that has 5 different 'basis' for returning the number of years between 2 dates. Only 1 of the 5 basis returns the correct 'age' for the pair of dates 2/29/1981 and 2/28/2008 - and that same basis doesn't report the correct age for the dates 1/31/1981 and 1/30/2008.