To Patch or Not To Patch

rubyonrails-core
1

Recently a lot of people I’ve spoken with have expressed that distance_of_time_in_words sucks for accuracy, providing values such as “about 2 years” where “2 years, 5 months, 3 days, 4 hours, 6 minutes and 42 seconds” is “more appropriate”. To fix this, I’ve written a plugin: http://github.com/radar/dotiw. I’m thinking that this should be in Rails core as it is a vast improvement over what currently exists, but I don’t want to put the effort into a patch that’s just going to be rejected, as per usual.

Who else would find this useful?

2

Recently a lot of people I've spoken with have expressed that distance_of_time_in_words sucks for accuracy, providing values such as "about 2 years" where "2 years, 5 months, 3 days, 4 hours, 6 minutes and 42 seconds" is "more appropriate". To fix this, I've written a plugin: GitHub - radar/distance_of_time_in_words: Better distance of time in words for Rails. I'm thinking that this should be in Rails core as it is a vast improvement over what currently exists, but I don't want to put the effort into a patch that's just going to be rejected, as per usual. Who else would find this useful?

The whole purpose of the existing method is to provide an approximate value, if that's not what you're looking for then you shouldn't be calling that method :slight_smile:

Given that your plugin is completely stand alone and doesn't need to override anything messy to keep functioning, I don't think we need to make the change unless millions of people are clamouring for it. Not to pre-judge but this is the first time I've heard this asked for, so I'm thinking we'll be best off leaving things as they are.

3

I wouldn't mind "about 2 and a half years" for the example in Ryan's
original, For the record, I can't think of any time I'd want "2
years, 5 months, 3 days, 4 hours, 6 minutes and 42 seconds" - sorry.

4

This is why I gave you :except options, so you can get 2 years, 6 months, for example.

5

Oh yeah, and if a value is 0 it won’t show it either.

6

lol @ “as per usual” How jaded we’ve all become. :slight_smile:

I would use this. I’ve built things like this a few times, and there’s always the case where I screw up and get “1 hours” (wrong pluralization) or “80 seconds” (instead of 1 minute 20 sec). Be nice to standardize going forward.

7

I just recently wrote my own to get exact results for everything minus the seconds for timing purposes in some logging. So your plugin with :except would have likely done the trick for me.

8

I'd be interested

9

I’d find it extremely useful. The current implementation sucks, for various reasons.

Actually, what you expect when you use distance_of_time_in_words, and what arguably should be the default in rails, is for it to output precisely what you input.

The method is not called rounded_distance_of_time_in_words, after all.

What you would expect:

helper.distance_of_time_in_words(1.hour) => “1 hour” not “about 1 hour” which it currently does.

helper.distance_of_time_in_words(1.hour+ 15.minutes) => “1 hour and 15 minutes” or “one hour and a quarter.” and not “about 1 hour” which it currently does.

Fancy rounding of hours and days should be something extra, for the people that need that.

For everyone else, there should be sane defaults, namely a convention that doesn’t violate expectation. You shouldn’t have to monkey-patch the app, or use an extra gem, to get the sane defaults.

Currently, this is how fancy it has become:

helper.distance_of_time_in_words(41.hours+ 59.minutes+29.seconds) => “1 day” eh… WTF? Since when did 1 day become 42 hours and not 24? Even according to the rounding principles used, this doesn’t make much sense.

Or these intervals:

1 yr <-> 1 yr, 3 months # => about 1 year

1 yr, 3 months <-> 1 yr, 9 months # => over 1 year

Who on earth would be able to deduce from the output that 1 year and 3 months is “about one year”, and not “over 1 year”?

See all the fancy roundings here in the docs, and see if you don’t agree with me.

Having the expected precision is especially important when using this in email communication towards users, or for communicating deadlines.

Precision doesn’t hurt, apart from being a bit UX unfriendly at times. On the other hand, imprecision and fancy roundings can be very damaging.

I vote that the relevant parts of the dotiw gem be made a part of core rails, since the default behavior should be intuitive and straightforward.

10

I’d find it extremely useful. The current implementation sucks, for various reasons.

Actually, what you expect when you use distance_of_time_in_words, and what arguably should be the default in rails, is for it to output precisely what you input.

The method is not called rounded_distance_of_time_in_words, after all.

What you would expect:

helper.distance_of_time_in_words(1.hour) => “1 hour” not “about 1 hour” which it currently does.

helper.distance_of_time_in_words(1.hour+ 15.minutes) => “1 hour and 15 minutes” or “one hour and a quarter.” and not “about 1 hour” which it currently does.

Fancy rounding of hours and days should be something extra, for the people that need that.

Which, presumably, would be everybody who is using this helper now.

For everyone else, there should be sane defaults, namely a convention that doesn’t violate expectation. You shouldn’t have to monkey-patch the app, or use an extra gem, to get the sane defaults.

You brought a 5±year-old thread back to life to insist that the current behavior is not “sane”. [citation needed]

Currently, this is how fancy it has become:

helper.distance_of_time_in_words(41.hours+ 59.minutes+29.seconds) => “1 day” eh… WTF? Since when did 1 day become 42 hours and not 24? Even according to the rounding principles used, this doesn’t make much sense.

Or these intervals:

1 yr ↔ 1 yr, 3 months # => about 1 year

1 yr, 3 months ↔ 1 yr, 9 months # => over 1 year

Who on earth would be able to deduce from the output that 1 year and 3 months is “about one year”, and not “over 1 year”?

See all the fancy roundings here in the docs, and see if you don’t agree with me.

Having the expected precision is especially important when using this in email communication towards users, or for communicating deadlines.

Precision doesn’t hurt, apart from being a bit UX unfriendly at times. On the other hand, imprecision and fancy roundings can be very damaging.

I vote that the relevant parts of the dotiw gem be made a part of core rails, since the default behavior should be intuitive and straightforward.

Make a PR then. Nobody has done it in the last 5 years, so I’m unconvinced it is a thing anyone wants.

If you really find the fancy roundings useful, leave it in rails, but rename it to rounded_distance_of_time_in_words, fix the bugs, and update it to support atleast half-hours, half-days and so on. Like this*:*

I dunno who “you” is in the sentence above. If it bugs you this much, again, submit a PR for discussion. You’ll need to explain why you want to make a breaking change in every app that uses a function that hasn’t changed in years, and you’ll need to provide a patch to deprecate the old names in the next 4.x series release.

—Matt Jones

11

I would argue that this should be a method, Ryan’s patch is actually a more accurate implementation of the current method. The current version should really be called something like approximate_time_in_words. However, it would be unrealistic to do that. I do think perhaps “exact_time_in_words” (or something similar) would be a good place for Ryan’s method to exist. I think if people had it available, more would certainly use it. As it is now, most people don’t think too much about it.

12

I think this thing is difficult to implement given the fact that months and years/leap-years lack symmetry. Implementing it would take lines and lines and lines of code and some headache unless someone devised something clever and concise thinking out of the box. The core team wont admit the fact that this got difficult and just excuse themselves that it is not needed instead of putting it out there for people to solve like Ryan has tried. Any rational person can of course see that in a web application, display of exact time is very important, especially is you have to count down deadlines(long or short), or allowed time for a user to access a resource. For it to look fair, a user got to see exact time.

Rails core have done a good job with the framework itself and no demands can be made on them, But it is important to admit that such a method as ryan syggests is needed. Like Yrs, Mths, days, hrs, mins, secs. and of course with a method to truncate accuracy.