91

Many sites will display dates or times in an inaccurate representation like 1 year ago instead of just displaying the actual date. Here's a case I found to be particularly annoying: enter image description here

This video mostly contains lots of news of recent scientific research, so seeing that it's off by 11 months makes me less interested because it's almost twice as old as it was being reported.

Why do sites do this? I feel like this is a bad user experience and I would rather just see the actual date than some estimation that could be really far off.

Improve this question
8
  • 26
    It's really annoying when you are trying to compare two dates as well, to see which came first, but they both say "a month ago".
    – Chloe
    Commented Jul 25, 2015 at 0:45
  • 3
    because it is more easier to tell the time this way
    – user69065
    Commented Jul 25, 2015 at 8:54
  • 5
    Oh man, good question -- this drives me CRAZY.
    – foobarbecue
    Commented Jul 25, 2015 at 20:44
  • 1
    The worst is in facebook messenger when someone sends you a message that says "next friday" and you want to see when they said that so you know if you missed it, and facebook tells you "about a week ago" or some crap.
    – foobarbecue
    Commented Jul 25, 2015 at 20:51
  • 1
    Any site that does this well also has the timestamp available when hovering over this blurb of text.
    – Seiyria
    Commented Jul 27, 2015 at 12:22

7 Answers 7

Reset to default
120

Imagine you’re telling a friend a story about a time you took a flying class. You want to give an idea of when the story takes place. What format should you supply the time in? Should you say “The date was 2014/12/31 and the time was 16:05:03 PST”?

Of course not. The point of the story isn’t the exact time you took the class. You want to focus on communicating the experience of flying an airplane, maybe a humorous anecdote about a mistake you made in the air. Being overly specific here would be strange and distracting—maybe even a little concerning.

Computers should behave like sane, helpful humans, just with a few computational advantages. When talking about most YouTube videos under most circumstances, the exact post date is irrelevant. If a special case warrants more precision, you can open the video page itself and see the date. Good job so far, YouTube.

However, there is a problem here.

The actual age of the video you mentioned is 1 year, 11 months, and 9 days—which is not even close to the advertised “1 year ago”. YouTube should have said 2 years ago. That’s what a helpful human would do.

Improve this answer
20
  • 15
    I think rounding up to 2 years is worse and not helpful.
    – whatsisname
    Commented Jul 24, 2015 at 5:03
  • 9
    Or it should say "1 year and 11 months ago" to be more accurate, but I don't think there's enough space for that.
    – Derek 朕會功夫
    Commented Jul 24, 2015 at 6:26
  • 108
    Perhaps it would be better if it said, "almost 2 years ago".
    – Stephan B
    Commented Jul 24, 2015 at 6:28
  • 52
    I want to know who's going to be teaching a flying class at four o'clock on new year's eve.
    – SinisterBeard
    Commented Jul 24, 2015 at 7:49
  • 15
    The spoken word and text is not the same. When I am telling about something that happened in the past, I don't remember exactly when. If stop and think a bit more about how it relates to other events, I will remember the time more accurately. But that process is distracting from the story much more than specifying a more accurate time right away would have. So I'd say being vague about the actual time when speaking is mainly about not remembering it more accurately. Moreover when reading it is easier to skip over and not pay attention to the exact time.
    – kasperd
    Commented Jul 24, 2015 at 8:14
47

Not enough reputation to comment, but on many sites with this "friendly" time, you can actually hover to get the exact time.

Try it over on this question's "asked" and "active" times on the right hand side.

Improve this answer
6
  • 4
    Last year, you had no reputation to comment, this year you have enough.
    – Uwe Keim
    Commented Jul 25, 2015 at 14:58
  • 59
    I'm hovering my finger over my handheld device, but nothing's happening.
    – John Kemeny
    Commented Jul 25, 2015 at 16:05
  • 1
    @PålGD try a long click
    – John Dvorak
    Commented Jul 26, 2015 at 12:46
  • 1
    @JanDvorak long-touch is mostly equivalent to a mouse right-click, not a hover. Besides, the technology that would allow PaiGD to do that already exists and I suspect will be appearing in mobile devices soon enough.
    – adelphus
    Commented Jul 26, 2015 at 12:48
  • 2
    @JanDvorak In the Stack Exchange app for Android, neither a normal tap not a long press on "Answered 6 days ago" does anything.
    – Damian Yerrick
    Commented Jul 31, 2015 at 3:44
24

This is the use of relative timestamps. In relative timestamps, accuracy isn't important, and immediacy of scanning prevails over accuracy, so things like this may happen, where you see "1 year ago" until Aug 15, 2015, where you'll see 2 years ago. There's a lot of controversy about this approach, and IMHO, it's correct that you could add something a bit more accurate, even if using relative timestamps, for example, measure the time in months, which could be an acceptable mid-way between accuracy and eye-scanning. But if you read the Adaptive Time Units section, you'll see that what you're getting is the norm, not the exception.

However, when you make an UX decision, some of these decisions have a trade-off cost, and I bet YouTube knows what's going on. But they may have a very small number of people perceiving your issue as a problem, and a HUGE number of people who will prefer a fast scanning data display. Thus, you get less accurate dating by weight of numbers

Improve this answer
16
  • 12
    I really can't see how "a year ago" is faster to scan than "Aug 2013".
    – Davor
    Commented Jul 24, 2015 at 8:50
  • 17
    @Davor because people generally think in terms of time points relative to now. Giving the date (not matter what format or precision) means that people have to calculate how long ago this was - it's generally considered easier for people to process dates and times relative to the present.
    – adelphus
    Commented Jul 24, 2015 at 10:57
  • 4
    @adelphus: "because people generally think in terms of time points relative to now" - isn't that limited to cases where people are thinking about now? When they are thinking about event X and want to quickly look at some videos that were posted around (or right after) event X, the relation to now seems irrelevant.
    – O. R. Mapper
    Commented Jul 24, 2015 at 15:06
  • 3
    @adelphus "people generally think in terms of time points relative to now." [citation needed]. I think it depends very much on the date, the person and the context. For example, the US declared independence in 1776 (not "about 240 years ago") but Magna Carta was signed in 1215 or 800 years ago (but, next year, we'll probably say "in 1215" rather than "about 800 years ago" or "801 years ago"). If you're planning your vacation, it may well be "in a couple of months" but, when you're booking the hotel room, it's "14th-20th September".
    – David Richerby
    Commented Jul 24, 2015 at 22:53
  • 4
    @DavidRicherby There is at least one notable instance where the date of the US declaration of independence was referred to by a relative timestamp, even one involving obsolescent ways to express the number 87 ...
    – Hagen von Eitzen
    Commented Jul 25, 2015 at 10:11
13

You've caught a common bug (IME) in the implementation of these relative time/date stamps -- at a step-change in the precision you lose a lot of information due to rounding, and the rounding is always down.

It's common (I assume due to a built in library) on Android apps to get "59 minutes ago" (more precise than needed) then "1 hour ago" displayed for the next 60 minutes (less precision than needed). If it was up to me I'd code your example to give "23 months ago". That's not to say I'm right though. Another option might be to give "just under 2 years ago" or "about 2 years ago".

I think it would be better to have something along the lines of 1,2,3,4,5,10 minutes followed by ¼, ½, ¾ hour up to say 3¾ hours, then integer hours up to ~48, days to 8, weeks to 5, months to 23 and finally years. This would make the loss of precision less sudden as the maximum ratio is ~1.5* rather than 2*.

As for UX reasoning, I would have thought that time zones would come in to it: throw the time posted and the user's time, both with time zones, at your standard date/time library to get a difference, then round. The user doesn't have to care about timezones then. Of course you could convert everything to the user's timezone (I've assumed you know it already) and present that but it's not necessarily helpful. Imagine a headline and timestamp "News just in: Mass pile-up in the morning rush-hour. 16:50 today". In fact Strava does something similarly daft - someone I follow is in New Zealand and I'm in the UK. Their morning commute shows up in my feed tagged as "today" when it should be "tomorrow" - and would be if dates were compared naively.

Improve this answer
2
  • 1
    Failure to indicate times such as "1¾ hours", "2½ hours", etc is common, it seems. I've noticed Twitter has issues with this - it seems like a post that's over 90 minutes old will often have a timestamp of "1hr". In Twitter's case, the irregularity of this function is exacerbated because sometimes these timestamps are updated periodically while the page is left open, but the lack of any division more granular than an hour is what makes it confusing.
    – recognizer
    Commented Jul 24, 2015 at 18:33
  • 3
    For step changes, I like the 1.5 rule - display units up to one and half of the next highest and then round after that (eg. 0..90 minutes, then 2,3,4... hours; 0..10 days, then 2,3,4 weeks; ) I think fractions can cause problems, but ultimately, there is no correct precision to please everyone.
    – adelphus
    Commented Jul 25, 2015 at 13:23
4

One plausible UX reason for this is preventing the situation where a user sees a date, fails to notice the year, and due to the proximity of month/day, assumes that the post was made within the past few days/weeks rather than (possibly many) years ago. This sort of user error can lead to embarrassing answers/comments/follow-ups on content where they're no longer relevant.

Improve this answer
4
  • 14
    Ah, the "You can't handle the truth!!!" school of UI design. Please don't hide information from me "to prevent me from making mistakes". I'm an adult: I'm responsible for my own mistakes.
    – David Richerby
    Commented Jul 24, 2015 at 22:33
  • 1
    I don't claim it's a good idea, just that this is a plausible reason it's done.
    – R.. GitHub STOP HELPING ICE
    Commented Jul 24, 2015 at 22:57
  • 1
    @DavidRicherby: I completely agree, the computer should also also let you be responsible for converting that byte strings to ASCII text yourself, and imagining what the HTML should look like. Computer's job is to display data, it should not try be a smartass and try to interpret data.
    – Lie Ryan
    Commented Jul 26, 2015 at 16:00
  • 1
    @LieRyan Can you think of any circumstances in which you wouldn't want that byte stream interpreted as text? I can't. Are the overwhelming majority of people interested in seeing the rendered HTML the overwhelming majority of the time? Yes. Is there a "Show source" option for people who don't want that? Yes. Those aren't remotely comparable situations to the computer being programmed to hide data from the user, on the assumption that the user will only ever want a gross approximation to what that data says.
    – David Richerby
    Commented Jul 26, 2015 at 16:40
0

this answer is in relation to other answers to avoid duplication with an extra bonus at the end

I agree that

  • The context of the story is the most important factor. You might be talking about what happened last summer and you have everything happening 11 months ago. So if you need to compare with other parts of the story then you need more precision.

  • Having a large collection of data to display means that the user will want a quick scan of the dates in relation to the "now" moment to filter out what he needs

  • You cannot please everybody, but you can keep trying and youtube has chosen to show a more precise date in the video page which seems sufficient.

  • The easiest solution is when having an inaccurate representation to have some way to display the accurate timestamp that works both in mobile (tap on the date to swap format) and in desktop (hovering the cursor and displaying tooltip)

I disagree that

  • The date should be displayed as a decimal (1.9 years) because it would be hard to do conversions and at the same time you have to imagine all this variety of numbers that will be displayed and is going to overload you. Instead it is easier to group in your head all the "1 month old" videos and the "2 month" old videos. In addition when you are relaxing watching youtube you don't want the list of videos looking like a spreadsheet, this means you are back in the office, not relaxing!

  • A single solution can be found for all users, and there is no optimization here. Different users will want different things or even think in different ways. For example a person might have a very large working memory and he or she can process more complex information than the average iq person without any hassle.

Design Opportunity

From reading this page we can all agree that we disagree on which is the best thing to display because there are some many different scenarios and segments of users to satisfy while the only available action is display.

First of all generically in my humble opinion any rendering of any timestamp should include your display format of preference that will be more suitable for the most use-cases being "almost 2 years ago", "more than 1 year ago" etc. and also the exact timestamp with an accuracy of a second (given that transparency of such data is ok).

So if you have this kind of information I would consider creating a browser add-on to give power to the user who requires it and change the text that displays the date locally on his or her machine. Boom! You have given a toolkit to the user and more often than not toolkits can bring an awesome user experience.
One implementation that comes into mind is for this add-on to add a small icon (as most of the add-ons do) and then start scrolling on the icon to swap between the different precisions.

Wouldn't be awesome to see the text change like this:
"1 year ago" -> "1 year and 11 months ago" -> "1 year, 11 months and 3 days ago" -> "11 Aug 2013" -> "11 Aug 2013 around noon" -> "11 Aug 2013 12:34" -> ...

Improve this answer
-2

Relative dates are terrible. Exact dates are best, and do not require refreshing the web page to make sure the relative date is correct.

Improve this answer
2
  • Are relative dates always terrible? Would you act differently if a generic video was posted March 12, 2015 or March 14, 2015? Or would the phrase "two years ago" suffice?
    – Mayo
    Commented Mar 13, 2017 at 21:31
  • This is not generally true. For most purposes, if something is more than a few months old, you don't need to know the exact day, just the month. If it's several months or years old, you probably only care about the year. And the best practice is to have the full time stamp available on-hover for those few that care...
    – ecc
    Commented Mar 14, 2017 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.