[bryne]

This is a ridiculous argument - relative dates are an enormous usability improvement for actual users, who don't care about machine-readable timestamps or the incredible mess that is timezones.

Twitter also doesn't give a fuck about archival via screenshots. I'm pretty hard-pressed to imagine who would, actually.

[run4yourlives]

"More than one year ago" - Actual Facebook date.

What does this mean? Is this picture older or newer than the other picture, also labeled "More than one year ago"?

[jerf]

Whenever I use relative dates, I usually draw the line at either one week or one month, after which I go to absolute dates. It can be cognitively challenging to see a date from two days ago and work out whether it was two days or one day, hey, today's Thursday right so that was Tuesday etc., whereas from 2012 a timestamp from 2009 isn't cognitively challenging to read as "years ago", and if you want the precision, it's there.

Personally when I've done it I often also simply always have the absolute time: "Wednesday, August 22nd at 8:22PM (a day ago)", with the order of the two elements chosen depending on which makes more sense.

[_delirium]

That'd be an improvement in HN, imo. Times like "12 minutes ago" or "3 hours ago" or even "9 days ago" are fine, but "1612 days ago" requires me to mentally convert to figure out when that actually was.

[dbecker]

The problem you are describing isn't a problem with relative dates. It is simply imprecision. You can make relative dates that are precise (e.g. 783 days and 4 hours ago), and you can make absolute dates that are imprecise (e.g. 2010).

[run4yourlives]

783 days and 4 hours ago is even worse!

What is that, like two years ago, oh maybe just over 2 years, oh shit no just under...

We have a standardized date system. It's been in use around the globe for years. It works. Please use it.

[briandear]

I vote we switch to the Julian Calendar. Of course, I'm partial to the Chinese Lunar Calendar. We could always use Unix time as well.

[halefx]

Hanke-Henry calendar is the most logical. http://www.wired.com/wiredscience/2011/12/rational-calendar/

[Aaronontheweb]

Now you're just being pedantic - displaying the number of days since a picture was taken is not worse than not being able to differentiate past 12 moths.

[polyfractal]

No, he isn't being pedantic. It's a real, valid usability issue.

"783 days and 4 hours ago" really is worse. If I am browsing a photo and look at that, my first reaction is "That photo was taken a long time ago". If my buddy asks when that happened, I'll have to start doing some simple math in my head. "Uhh, around two years ago? So what, that's 2010?"

Simply putting the date would have been a much friendly solution. You know immediately that it was "a long time ago" because everyone knows what the current year is. And you know what year immediately.

Conversely, on short scales it's opposite. I don't really care if a post was on Monday or Tuesday (usually). I care that it was recent. Providing the exact timestamp doesn't help.

Both have their uses.

[jtheory]

Agreed, on this one.

Think about the task of correlating online events with events from your memory.

Suppose you see a quote from you, saying something rude that seems out of character. Knowing that it was however many hundreds of days ago is useless; see that it was July 27, 2011, at 4am, and you'll say "oh, yeah, somewhere in late July we had X and Y over drinking into the wee hours... those #%#$%s must have been futzing with my computer after I fell asleep, and somehow I never noticed".

Most importantly -- you have to predict the reasons people will be looking at dates, and this varies. Gmail shows both because they can't guess; email can carry so much different stuff.

HN post/comment timestamps beyond a few days ago can be notated in number of days as far as I'm concerned; I don't need to know what year, even -- just "this is old".

The timestamp on a blood sugar reading should include time of day (and possibly day of week even) -- a full timestamp, minimum -- to be useful.

Etc..

[jarek]

My HN profile was created 864 days ago. When was it created?

[icebraining]

This is why I'd love to have knowledge engines like WolframAlpha integrated everywhere (or at the very least, as a CLI program).

http://www.wolframalpha.com/input/?i=864+days+ago

[theorique]

Just over two years ago. (730+ days)

If I needed an exact date, I would do something like the following (python)

>>> import datetime >>> datetime.date.today()-datetime.timedelta(864) datetime.date(2010, 4, 13)

[jarek]

Well, see, I would just print the date that's there in the database in the first place. How is "864 days ago" useful information? Doesn't everyone at least convert it to the number of years it stands for?

[dnr]

Easier in shell:

  $ date -d '864 days ago'
  Tue Apr 13 13:46:16 EDT 2010

[saraid216]

Ooh, ooh, I bet it was a January.

[badclient]

Two things:

(a) relative dates are much less useful further they get from present date; Facebook should probably have a cut off after which exact date is shown

(b) relative dates do not replace exact dates; you should still make it relatively easy to see the exact timestamps even if it requires an extra click

[chrisrogers]

Relative dates are effective up to a point. People think relatively about events for perhaps a month or two. Past that it probably becomes more effective to use absolute dates.

[prawn]

Put the actual datetime in a title attribute. Or have a sort by date option.

[Ideka]

That is a problem with Facebook, not with relative dates.

[ecesena]

+1. I'm not a fan of relative dates as a user (although I maybe a too "scientific" mind) but I can't see any other way to display dates if timezone matters.

When timezone no longer matters, e.g. after a few days, then I would switch back to absolute dates exactly to avoid such incomparable expressions.

[lucian1900]

The problem is that Facebook doesn't include both.

[mehulkar]

I'm an actual user who doesn't really care about machine-readable timestamps and I would prefer absolute dates. The gmail solution in post works for me too.

[briandear]

I totally agree. UX should not be based on some engineer's idea of what might be useful but on what might be useful to the actual user. Seeing August 22 doesn't mean much to me because I don't constantly look at my calender, but seeing 1 day ago or "yesterday" lets me know when something happened without me trying to remember what today's date is.

However, that being say, I thing relative dates do have a point of diminishing returns. For me, past a week is when I'd prefer to see actual dates.

I do agree that "over a year ago" is pretty vague at not as useful to the user as "August 2011." The word "about" gets ambiguous when dealing with longer spans of time. Obviously "about" is ambiguous by definition, but the degree of ambiguity increases as one goes further away from the event.

[acdha]

The best part: Twitter actually already does something very similar what he suggests, with their relative dates having a data-time attribute containing the Unix timestamp for each tweet. If he wants to throw away source information and store pixels representing how a particular browser rendered it, well, that's not Twitter's problem.

His microdata example is also only write if you having upgraded to HTML5, in which case <time> is obviously better.

[eevilspock]

It's much more sensationalist and page hit attracting to make absolute black or white claims rather than something nuanced. How many hits would "When to use relative versus absolute time" get?

It's on the HN front page. Look at this thread. The joke's on us.

[electic]

I disagree. I think the date should be there so I know exactly when it happened. This is especially critical in realtime systems. I have seen some horrid relative date instances. On Pinterest, for example, I have seen "about a year ago". Really?

[jamesaguilar]

If you can recognize cases where timestamps are important, you should be able to recognize cases where they aren't, too. Why does it matter exactly when a Pinterest item was pinned? Answer: for the vast majority of cases, it simply doesn't.

[run4yourlives]

But the stupidity is that you are taking away something for no good reason. You already know the date of the pin. You figure it's important to show this, but then you make it completely useless instead of providing the already useful piece of information you actually had.

[lucajona]

Providing perfect information isn't always as important as providing information that's quick and easy for people to process.

Take a piece of information like '12 Apr 2012 10:09 AM PST'--there's a fair bit of mental arithmetic required to work out how long ago that was, if 'how long ago' is important to you. And it's different arithmetic depending on whether you're looking at it on the 12th of April (time zone adjustments, crossing noon)or the 14th of June (how many days in April and March). Multiply this by the number of dates on a screen, and you might end up with a lot of information noise.

A lot of the time, a quick, rough idea of 'how long ago it was' is really helpful. I wouldn't be so quick to label relative dates as stupid. Information overload is a real problem for humans, not so much for computers. It really depends on the circumstances, but for most UIs designed to be read by people, relative dates can work really well.

[jeltz]

I would say such calculations are made much easier if time stamps are expressed in ISO format where all parts of the date are in order and numeric.

2012-04-12 10:09 PST

Since it is August 2012 now it is roughly 4 months ago (and one rarely needs more precision than this).

[jfrankamp]

So "roughly 4 months ago", I'll take this as a +1 for relative dates.

[electic]

It really does matter because "a year ago" is VAGUE. Is that 1.5 years ago? 1.1 years ago? 1.6 years ago? And depending on the content, it is even more critical. Let's say it is a sporting event of Usain Bolt. Did that amazing shot of him running happen in the Olympics or at a meet? No. Idea.

[tsieling]

If you can make a case for why you need an absolute date at that level for a Pinterest item, then I'd be all ears. But for now these use cases demanding absolute dates for ephemeral social media content seem ephemeral.

[sbauch]

Absolutely agree about realtime. Just ran into this issue. Relative timestamps on content that is live updated gets stale immediately. The user has to refresh the page to get an accurate timestamp, which sort of defeats the purpose of the realtime content. So we switched to absolute.

[jfrankamp]

Software issue... updating the relative dates occasionally without a refresh is trivial. My twitter client does this.

[aaronpk]

I'm guessing they do actually care about screenshots, given that they have been recently restricting the ways they allow people to display tweets.

They did change the format they used when displaying individual tweets, I'm guessing this was intentional.

[bryne]

I don't think they care about screenshots specifically, but they certainly do intend Twitter.com/.app to be the primary or only method that tweets are displayed, ever. To this end, relative dates are great.

You do have a good point that touches on the dilemma of the internet archivist, but this is certainly a problem easier to solve than the ones faced by people attempting to preserve software or video games, for example.

[stephengillie]

How is the relative timestamp not machine-readable? Can the computer not be programmed to parse If (4_characters_after_timestamp == " ago") {$timeoftweet = $now+$timestamp} ?

[mgurlitz]

One of the author's points is that relative dates discard information. 10:37 and 10:36 are both encoded as "9 hours ago," and therefore you can't map back to absolute dates without potentially losing order.

[icebraining]

That's a matter of implementation, not a specific property of relative dates, though.

[bryne]

Sure, but that seems harder than attempting to shame developers into changing the way they display timestamps.

[kineticflow]

Not every website is in English.

[thinkingisfun]

Give it some time.

[Lozzer]

If you're parsing from a real time feed, then that's fair enough. But if not $now isn't appropriate.

[tripzilch]

I dunno, I find the GMail inbox less usable for pretty much the exact reason he gives in the article. When I see an unread mail with "yesterday" or "one day ago", I'd like to know whether this mail--that I apparently overlooked--was sent yesterday morning or evening, so I can know whether the person expected me to reply yesterday or today when I see it.

[spullara]

Twitter dates include machine readable timestamps in the markup. Also, you should be using tweet embeds which will remain up to date :)

[rio517]

I couldn't disagree with you more. It would be relatively trivial to adjust a date for a users local timezone - as if often done.

[badclient]

The problem isn't a technical one related to timezones. The problem is that full date/timestamps are less useful for a reader to see than relative dates in many cases.

[saraid216]

Using relative dates is basically saying, "Our old stuff has no worth to you. Please never care about it."

[badclient]

How?

[saraid216]

Explain why relative dates are more useful. You'll see it.

[rayiner]

But if a user sees a post on someone else's feed, do they know if the timezone is adjusted or not?

[mvgoogler]

I agree. I read that article as "Don't use relative dates - it makes it hard for me to scrape your content".

[indiecore]

Why not both?

if the date is less than a couple of days old (or whatever threshold works for you) display a relative date. This is useful because in the short term relative dates are more useful to the user. If it's older than the threshold display a YYYY-MM-DD H:m:s or whatever format floats your boat.