Relative dates/times- Rounding and how accurate?

Question

I was reading this question about formatting relative dates and times, but there are still some issue that I felt have not been addressed yet.

I would like to:

• Keep relative times to just 1 unit, for example 1 hour ago as opposed to 1 hour and 24 minutes ago.

• When the time/date is hovered, we display the localized date, for example, Tuesday, 24 July 2012 at 10:00 PM.

Given the above:

• Should I round up or round down times? For example how should I turn 1 hour and 24 minutes ago into just hours?

• Should I display relative days as Yesterday, 2 Days ago, 3 Days ago, or Yesterday, Tuesday, Monday?

• At what point should I stop with the 2 Days ago, Tuesday, Monday and revert to displaying localized dates?

• Should I bother having relative time/dates for weeks and months?

• When should I drop the time component and just display the date/day?

Answer 1

• Rounding - you should apply the same rules you would to a floating point number so "1 hour 24 minutes" is less than 1.5 hours so it should be rounded down to "1 hour". When you pass 30 minutes then round up.

• I'd go with "Yesterday", "2 days ago" etc.

• A quick check on Stack Exchange shows that they use "Yesterday", "2 days ago", localised date, while (as you point out) Facebook goes for the days of the week. I think that the answer depends on how accurate you need the date to be. Do your users need to know the exact date (easily worked out from "today" and "yesterday", but slightly harder to work out from "Monday" or "Friday") or is "some time this week" or "recently" good enough?

• If you're already displaying older dates as the actual date rather than "some time ago" when the date is a 2 or 3 days old, then having relative dates for weeks and months seems to be irrelevant.

• While the time component for a date that's a year old appears to be irrelevant, it's probably not worth the extra coding effort to hide it for older dates. The benefit (if any) of hiding the time probably isn't worth the cost of writing and maintaining the necessary code.

However, with all of these it depends on how accurate you need your dates and times to be. Is it important that the displayed value is as accurate as possible or is the exact date/time on a tooltip OK?

Answer 2

Firstly, I'm assuming that you have a very good reason for not wanting to use multiple units. In general it's best to use units that people naturally use, and most people would go more with 1 hour 14 minutes than just whole hours. But giving you the benefit of the doubt on that, assuming you had to, this is what I would recommend:

If the time were 1 hour 45 minutes ago, then don't round up to 2 hours, because most people will take the time given as a minimum amount. Use some word to give a context, for example:

• about 1 hour ago (best option), or approximately 2 hours ago (less like human speak though)
• less than 2 hours ago (only works well if you always round up).

If you're going to go the route of rounding to single units, I would keep showing the date in relative terms and just give the exact date/time when someone mouses over it or clicks on it. so, I would keep the units to: minutes, hours, days, weeks, months, and years. Suddenly switching from a relative time to a precise time is confusing and you should avoid it.

Answer 3

Rounding: Understand that rounding will always create incorrectness. If you really want to go ahead with the idea, here is my suggestion:

Let's take "weeks" as an example to explain my concept. (You may want to grab a calendar now...) The day today is Thursday 26 July.

• Suppose I went to the doctor on the 14th of July. That's 2 weeks ago, right?
• Suppose I went to the movies on the 2nd of July. That's 3 weeks ago, right??

At first sight this may seem like a simple mathematical rounding thing (Symmetric rounding?), but it's not!

Assume that the day today is Saturday 28 of July. Than both my examples are still valid: I went to the doctor 2 weeks ago and went to the movies 3 weeks ago.

You must not look at the time span itself and round that. You have to determine in which week the past event happened (i.e. Week 27 for the movies) and in which week the current day is (i.e. Week 30). Subtract both (30 - 27) and that's the time difference in weeks!

You can apply this concept to any time unit: hours, days, weeks, months, years, centuries,...

It's the most natural thing to do when you don't want to use expressions like "approximately", "more than", "at least", "almost",...)

Answer 4

It seems that there is no common solution for such case — it depends on tasks and goals. I had a case for dashboard displaying warranty & repair information about equipment. I made such assumptions (maybe inappropriate to common cases):

1) Making roundings for timestamps and dates are incoorect, because it is not possible to make difference between correct and rounded values — the user may be confused. Only relative values ("1 hour 23 minutes 35 seconds ago") should be rounded.

2) The nearer the date/time to present date/time, the more accurately it should be displayed. For instance, if it is two days to start an review/repair activity — it should be displayed as 2 days (with an exact date and time). But if the equipment should be checked at 2015.12.28, it is enough to say "more than 3 years, at "december 2015", or event "at 2015".

3) More human and task-oriented, and less mathematical roundings are better. For instance, "1h29m ago" can be rounded to "more than one hour ago" for alert messages and to "less than two hours ago" for news feed (but the usage of such text format instead of numbers should be additionally checked for readability — for instance, it is usually not applicable in lists or tables).

4) Combining both exact date and time and, visually separately, rounded relative value is more effective in date/time critical applications (for instance planners and this dashboard).

So, with such assumptions, answers to your questions:

1) Yes, roundings are applicable for relative values, because they are easier to understand (no necessity to compare with current time).

2) Using day names instead of realtive values can be harder to understand, cause it also requires additional cognitive efforts.

3) Yes, relative values for days and months can be useful in some date/time crytical scenarios, but in case of simple informative messages (as in news feeds) it is unnecessarily.

4) Time can be dropped if it is not vital and if the moment was more than two days ago (or will be after two days).