[bernardwilson]

This is the wrongest thing I've read in ages.

a) Who cares about screenshots? "I'm going to the pub on Thursday" suffers from exactly the same issue. b) Nonsense. Of course relative dates are machine readable. But anyway, web rendering != API. c) These examples are not ambiguous, they are merely less precise

And less precision is, indeed, often what a user wants. That's why we don't print "posted 124568080nanoseconds ago". Simplifying to a reasonable unit, appropriate to the application, reduces cognitive load on the user. Most people struggle to tell you today's date, let alone knowing how long ago an arbitary timestamp was.

I like twitter (who maintain a relative date on the top-right of the feed entry) and gmail exactly the way they are.

[dredmorbius]

"I'm going to the pub on Thursday" isn't likely to be archived and referenced at some future date.

Unless you Tweet it. In which case, your statement (and the relative, human-parsable time) and the timestamp (absolute, machine readable) are both present.

Repetition and redundancy can increase robustness and strength.

[bernardwilson]

This would be a valid argument for not persisting dates as relative values.

It isn't an valid argument against presenting dates this way.

The OP's POV seems, to my eye, driven by the fact that primitive screen-scrapers can't just run a simple "toDate" function to provide it, API style, to some back-end. But it doesn't mean that it's not possible to convert them - it's not even that hard.

Fortunately, UI designers care more about their actual users than satisfying 3rd party leeches.

[aaronpk]

Gmail is a great example because they show both the relative date as well as the actual time, so you get the best context.