In our app we need to display the amount of time passed since an object was created in the UI. Out of the box it looks like time_ago_in_words
was going to do the job. However, in our case we need to know the time in a specific unit, in this case days. By happenstance the important numbers are in the 120 days range which causes time_ago_in_words
to swap to ‘months’. We had to create custom method to handle this which partly duplicates the Rails code.
I have a patch to distance_of_time_in_words
that allows the user to specify a units:
option to force the returned value to be in the unit defined. For example,
?> distance_of_time_in_words(5.hours, 0, units: :minutes)
=> "300 minutes"
?> distance_of_time_in_words(5.hours, 0, units: :days)
=> "0 days"
?> distance_of_time_in_words(128.days, 0, units: :days)
=> "128 days"
?> distance_of_time_in_words(380.days, 0, units: :months)
=> "13 months"
?> distance_of_time_in_words(128.days, 0, units: :years)
=> "about 0 years"
This would uses the locale code that is already present in the method. Right now I didn’t consider a fallback if a time gets large, (e.g. user chooses minutes but the diff is 5 years so it results in a very large minute value) as it the user’s choice to keep that.
Looking for feedback and/or opinions on pushing such a patch up.