On Friday, February 6, 2015 at 6:01:48 AM UTC+3, Matt jones wrote: > > > On Feb 5, 2015, at 8:35 AM, Magne <mag...@gmail.com <javascript:>> wrote: > > 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 > <http://apidock.com/rails/ActionView/Helpers/DateHelper/distance_of_time_in_words> > 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 > > > helper.distance_of_time_in_words(1.hour+ 29.minutes) => "one and a half > hour" or "one hour and a half." and not "about 1 hour" which it > currently gives > > There is already established a precedence for including halves. It > currently supports half-minutes: > > helper.distance_of_time_in_words(0, 39.seconds, include_seconds: true) => > "half a minute" > --- > > cheers, > > Magne Gåsland > > fredag 7. august 2009 07.44.11 UTC+2 skrev Ryan Bigg følgende: >> >> 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? >> >> -- >> Ryan Bigg >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-co...@googlegroups.com <javascript:>. > To post to this group, send email to rubyonra...@googlegroups.com > <javascript:>. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > > 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
