Twitter also doesn't give a fuck about archival via screenshots. I'm pretty hard-pressed to imagine who would, actually.
What does this mean? Is this picture older or newer than the other picture, also labeled "More than one year ago"?
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.
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.
"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.
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.
If I needed an exact date, I would do something like the following (python)
>>> import datetime
datetime.date(2010, 4, 13)
$ date -d '864 days ago'
Tue Apr 13 13:46:16 EDT 2010
(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
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.
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.
His microdata example is also only write if you having upgraded to HTML5, in which case <time> is obviously better.
It's on the HN front page. Look at this thread. The joke's on us.
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.
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).
They did change the format they used when displaying individual tweets, I'm guessing this was intentional.
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.
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.
If you're making your users' experience worse out of a fear of breaking the relative value of screenshots you might need to re-examine your priorities.
A browser/extensions could add a tooltip or context menu item to time elements, showing relative and absolute dates regardless of the way it's authored.
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.
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.
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.
At first, I'm tempted to think "oh that must be from this year then", but I'm often wrong and it's just a floating date.
Hopefully the <time> element catches on, so I can make my browser display dates however I like.
created: 2012 days ago
Got any idea how long I've had an account for? I sure as hell don't, because 2000 days is a completely irrelevant measurement to me.
It would be a lot cleaner just to say that I've been around here since 19 Feb, 2007.
I think this is a bigger point than just the dichotomy between dates. If you are trying to make them mean something, make them mean something. 2 hours ago is fine, but 23 days ago is most certainly not. Was that a weekend? A morning? Last Tuesday after work? Who knows.
Actual dates work for longer periods of time, relative much better for shorter frames. Stick to this, for the love of God please.
sometimes you need a relative date. sometimes you need an absolute date. saying one is always bad and the other is always good is stupid, it all depends on the context.
We have a system for understanding time that is universal around the world. Instead of presenting me with information that is in that format, you're making up a new one for no good reason.
saying one is always bad and the other is always good is stupid,
Well, yes, which is why I didn't say anything like that.
X-Sent: 4 weeks, 19 hours, 13 minutes, 20 seconds ago
(Of course, it being gnus, the time updates while the message is in the article buffer.)
How is "2 hours" computed? Android does this by checking if the >120 minutes has passed. Which is mindboggingly incompetent.
Especially when it comes to days. So, I had a call to me that was made 1 day and 23 hours ago. I look in my call history and it says that it was "1 day ago", and I'm like. Wait? That can't be right, I didn't make that call yesterday.
One hour later android changes it to "2 days ago", no sentinent being in the history of the universe has ever, or will ever, think about in that way. And just by seeing "x days/hours" ago I have no idea what is actually meant.
This post was made <span title="2012-08-23 2 PM EDT"> 2 hours ago </span>
This solves the problem of both clutter and practicality. Now whenever you need to know the absolute time, just hover over the relative time and it will also show up in screenshots!!
For non-commercial apps, lately I've been displaying relative time, but embedding the actual datetime (in UTC) as a title attribute.
recently I published a python module to calculate the ago: http://pypi.python.org/pypi/ago
Nice article otherwise.
Then it would be complicated for the users living in USA to read the status of His Japanese friend that is stamped with a future date while it was actually posted a minute ago.
Which Time-stamp you want to use. the Client or the Server ?
Imagine a user in London using a server in Singapore, which time stamp you want to display, the Java-script generated Time-stamp for the Client's browser in London, or the Server time-stamp in Japan ?
I think Gmail's format is the best of both worlds, but we don't have the space for it in our sidebar gadget.
Finally, the screenshot argument isn't very convincing, and neither is machine readability or ambiguity. They're formatted for humans, and they're ambiguous on purpose.
The argument for screenshots is valid, however, sites like failbook where you see the post progression as X minutes ago still provide you the quick glance benefit of relative dates.
The real problems:
1. Old relative dates aren't useful.
- Instead of "1 year ago" give me a real date. I can figure that out for myself. OR give me the option of getting a real date easily (hover, or click, or something).
2. Relative dates are shared statically.
- Listen for print-screen commands and swap things to relative dates. (I have no idea if this is possible. I actually would bet that it isn't, but maybe it should be.)
- Make embedding real HTML much easier so when people think about embedding tweets they don't choose images just because they are easier.
- Make embedding real HTML much more advantageous (real retweet button, view conversation button, etc.) so that people want to use it instead of static (read: lame) images.
If it were, a lot of people would immediately (ab)use it to make screenshots impossible. You might consider that a positive or a negative, depending on your perspective.
Edit: although, on a Mac if you listened for `Cmd` or `Shift` you'd catch the print screen command. And I don't think anyone would complain that the dates changed on Ctrl press.
Of course you might still be screwed on other OSes.
Relative dates are a blessing where space is a constraint
If you're taking screenshots of things, that's your own prerogative.
Wouldn't including the relevant timezone be even better?
This solution linked from your second link looks more correct.
But still I am not sure if this is the right way to do it.
I actually find this pretty convenient. I don't remember days numbers. 5 days ago gives me a perspective. If I want the exact time, I'll just unfold the email tab. (I'm talking about the Gmail example he picked)
The more interesting question is, what is the best (easiest to read) way to format a full date? I believe it is: 8/1/2012 10:10:48 PM. I find twitters format slower to read: 10:10 PM - 1 Aug 12.
Timestamp (00:00am/pm) within 1 day
Day of the week (Monday-Sunday) within 1 week
Full date (00/00/0000) everywhere else
I also make sure I provide a way to view the full date (eg Saturday 1st December 2012 at 1:27am) somewhere in a 'more details' modal or pane.
I agree with others that the argument is pretty weak considering twitter screenshots are one of three reasons why we should avoid relative dates. But i would have felt it genuine if the thesis was his last sentence: "Avoid displaying relative dates, but if you feel like you absolutely need to, follow these best practices: ..."
What does annoy me though is when you have 05-06-12, is that dd-mm-yy or mm-dd-yy?
And also, doesn't Twitter's extreme attention on embedded tweets lately underscore how little they care about screenshots? Not to mention the fact that while they have, as the post suggests, resorted to timestamps on individual pages, they are still using relative timestamps in the main stream.
As a user, I prefer relative time. And since relative time views are almost always displayed in sequence, most of the arguments laid out in the post fail to matter.
The problem is that the app serves a worldwide audience, and I don't always know the locale of the user. By showing relative dates, everyone feels happy that they are seeing today's horoscope today. With absolute dates I'd get a lot complaints that they were seeing yesterday's horoscope for instance.
In the long run relative dates are more confusing for screenshots, leaving a page open, etc as stated in the post.
Personally I prefer relative dates, because that's the information I'm looking for. I don't care if some screenshots break; there shouldn't even be any reason to take screenshots of tweets etc.
This part made me feel the argument is suffering from confirmation bias. Twitter has only removed the relative date from the page where a tweet is accessed directly, not in the timeline where the relative timestamp is absolutely relevant.
1. Why are you sharing information in screenshots in the first place?
2. Use appropriate microformats and tags for marking up dates, so you're free to display whatever to the user:
<time itemprop="datePublished" datetime="2012-08-04T22:33:31">2 weeks, 5 days ago</time>
I'd also prefer that your website not high jack the back key-command so that I could go back to Hacker news without clicking the back button in my browser.