9 ms·

Why you should not be displaying relative dates.

213 points by caseorganic 14y ago

grecy 14y ago
> Now, Twitter uses the format "10:42 PM - 15 Aug 12" Wouldn't including the relevant timezone be even better?
- aaronpk 14y ago
  That would be very helpful actually! Good point.
  - aero142 14y ago
    If you figure out how to do that without it being an account setting option, you let me know.
    - TillE 14y ago
      I'm not a web developer, but can't you do that with Javascript? http://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp http://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/ http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zo...
      - jeltz 14y ago
        Neither of those two solutions are correct. They only work in a some cases. You need a more advanced detection algorithm for this. Preferably one based on the Olson database, since time zones have changed over the years and you want to be able to display past dates correctly. This solution linked from your second link looks more correct. https://bitbucket.org/pellepim/jstimezonedetect/src/e265c8eddec7/detect_timezone.js https://bitbucket.org/pellepim/jstimezonedetect/src/e265c8ed... But still I am not sure if this is the right way to do it.
uranmoron 14y ago
Incredible timing, I was just thinking how irritating this is on Github.
- danso 14y ago
  And on HN.
- jlcx 14y ago
  I'm glad I'm not the only one.
jere 14y ago
I think a bigger problem is absolute dates with no year; I've seen this on blog posts and comments (can't remember any examples right now though). 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.
- marsvskittens 14y ago
  Equally frustrating is when dates are displayed without the weekday, especially when trying to schedule an event. "August 30 2012? Wait, is that a Tuesday or a Wednesday?" Hopefully the <time> element catches on, so I can make my browser display dates however I like.
  - untog 14y ago
    Personally I think that's an event only argument. I couldn't care less what day of the week a blog post was written, for example.
    - aaronpk 14y ago
      Great point about displaying event dates. I think there should be some display guidelines based on the type of content the date is describing.
    - MartinCron 14y ago
      That's a good example about why there's no one-size-fits-all approach to displaying dates and/or date intervals. I care what day of the week I fly. I care if someone commented on my picture 2 minutes or two hours ago. I don't care about the local timezone of someone else's server.
- jlcx 14y ago
  Here's one that has confused me: http://buyersguide.macrumors.com/ http://buyersguide.macrumors.com/
- mmcnickle 14y ago
  I find a frustrating number of sites don't put any date on their articles/posts. Everything on the web should have a visible date somewhere.
noblethrasher 14y ago
You probably shouldn't hijack the keyboard shortcuts for the back button either. Nice article otherwise.
- aaronpk 14y ago
  It's supposed to catch the left and right arrows. Didn't notice it also caught the back button! thanks.
  - aaronpk 14y ago
    Fixed it!
    - michaelhoffman 14y ago
      Not for me (Firefox/14.0.1 on Windows 7)
    - noblethrasher 14y ago
      I'm afraid not: Chrome21/Win7
      - aaronpk 14y ago
        ok, really fixed it this time
        noblethrasher 14y ago
        Nice!
jerhinesmith 14y ago
As a sometimes developer of web applications, relative dates nicely (for me) solve the problem of timezones. "10:42 PM - 15 Aug 12" means nothing without the relevant timezone information. "30 minutes ago" is timezone agnostic. For non-commercial apps, lately I've been displaying relative time, but embedding the actual datetime (in UTC) as a title attribute.
- foxhop 14y ago
  Agree. I prefer "ago" and your suggestion of a title/hover/hidden datetime is an even better idea! recently I published a python module to calculate the ago: http://pypi.python.org/pypi/ago http://pypi.python.org/pypi/ago
dllthomas 14y ago
Rounded dates make it less obvious when you've been posting during work hours...
bryne 14y ago
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.
- aaronpk 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - bryne 14y ago
    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 14y ago
  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} ?
  - bryne 14y ago
    Sure, but that seems harder than attempting to shame developers into changing the way they display timestamps.
    - deleted 14y ago
ars 14y ago
An entire article on dates and not even the slightest mention of timezones?
- gshaw 14y ago
  This. How can you display a time and mean something if you don't know what timezone the user viewing it is in?
  - icoloma 14y ago
    It gets even worse with DST. is GMT+2 meant to be Spain in summer, or something else? Relative dates are a blessing where space is a constraint
nostromo 14y ago
"2 hours ago" is actually more informative than "1:08 PM 23 Aug". The latter requires a location to be exact (1pm where? Is this being localized? Do you guys use daylight savings?) and the former does not.
- bobbles 14y ago
  Can't we just display both? 2012-08-23 1PM (2 hours ago)
  - aaronpk 14y ago
    Yep, Gmail shows both and it works well!
    - arctangent 14y ago
      I concur. I do think the "5 minutes ago" type of message should be shown first, with the detailed date/time in brackets afterward. What the users want/need is probably the key driver in this kind of UX decision though.
  - calciphus 14y ago
    Depends where you're displaying it. There's a pretty big clutter-and-space consideration for a time stamp that's 3x longer.
    - devcpp 14y ago
      Send a usual absolute time stamp and let the client compute the relative time, hoping it is accurate.
    - nivla 14y ago
      I think the best way to display date/time is to have the text in relative date/time and title in actual date/time. For example: 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!!
mikey_p 14y ago
So you don't prefer them and that's why I shouldn't do something? 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.
luney 14y ago
I find relative dates to be the most useful, most of the time. The scenarios where needing the exact date or time come less frequently. 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.
Geee 14y ago
The reason why relative dates are used is that you don't have to worry about timezones. You either have to get client's timezone and reformat dates, or use static timezone and let users do the conversions in their heads. 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.
bernardwilson 14y ago
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.
- aaronpk 14y ago
  Gmail is a great example because they show both the relative date as well as the actual time, so you get the best context.
- dredmorbius 14y ago
  "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 14y ago
    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.
verisimilitude 14y ago
Here's what I do. First, the markup: <time datetime="2011-08-27T19:15:38Z" pubdate>27 Aug, 2011</time> So, time in [ISO 8601][0] format. Run JS to transform '27 Aug, 2011' into a relative date. If the relative date is >1 month (or, whatever you'd like), then just display the full date. [0]: http://en.wikipedia.org/wiki/ISO_8601 http://en.wikipedia.org/wiki/ISO_8601
- cheald 14y ago
  Ding ding ding. Machine readable and user-friendly. 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.
  - mmahemoff 14y ago
    And cacheable too.
  - jonhendry 14y ago
    If it stops one long-since-debunked urban legend from being propagated via a screenshot of an old, relative-dated post, it's probably worthwhile.
- jacobr 14y ago
  This would even let users change the date back with a user script. 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.
tb303 14y ago
ridiculous argument and bad misinformation. relative dates are better for users in any context involving event freshness/recency, and they are machine readable by using many well-known markup techniques, including the microformat he mentions.
noblethrasher 14y ago
Create an `@media print` css rule that displays absolute date/times (with time zone). That's just about the best of both worlds.
binaryorganic 14y ago
I agree with all the dissent posted here. 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.
nilved 14y ago
Why would you ever use `abbr` with `title` instead of `time` with `datetime`?
- cheald 14y ago
  <time> is HTML5, which not everyone is on.
gatordan 14y ago
I dislike when an author titles and formats their post in this way. The title is an overstatement about why something that is common practice is wrong ("hey! i use relative dates, what am i doing wrong?"), leading to an article with a couple interesting points, ending with a concession that common practice is actually OK but could be better. 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: ..."
kapowaz 14y ago
This sounds like more of an argument for why you shouldn't be distributing stuff in the form of screenshots (although the horrendous entropy of the web is a compelling argument in favour of that, I realise).
run4yourlives 14y ago
Lot's of love for relative dates, but personally, I agree with the poster. Here's an example from HN: user: run4yourlives 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.
- rane 14y ago
  I'm afraid HN isn't very notable for good UX in general.
- MartinCron 14y ago
  The "2012 days ago" is just a sub-optimal implementation of relative dates. It could be expressed as the more comprehensible but less precise "over 5 years ago" with the actual date either nearby or in the title=""
  - run4yourlives 14y ago
    Or you could just show me the actual date, since it does everything a person needs it to do already.
  - deleted 14y ago
    [deleted]
- notatoad 14y ago
  Okay, but how is Feb 19, 2007 relevant information to you? If you were trying to schedule something based on your HN Join date, then i suppose you want the actual date. In the general case though, the date on your profile is only used by other members (or maybe moderators) to get a rough idea of how long you've been a member for. I can look at your profile, see 2012 days, and understand immediately that you've been an HN member for a long time. I've learned everything i need to know, and i've learned it quicker than i would have by reading a full date and subtracting it from today's date. 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.
nodesocket 14y ago
This totally depends on context. For example, on HN, relative dates are great, it is much easier to see how old posts are at a glance. However, anything where date is important, use the full representation. 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.
- ajanuary 14y ago
  8/1/2012 suffers from the dd/mm vs mm/dd problem.
idoh 14y ago
I'm the PM for a horoscopes app, and I much prefer to use relative dates (e.g. yesterday, today, tomorrow) instead of absolute ones (e.g. wednesday, thursday, friday). 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.
csomar 14y ago
If you're looking at an email and it says "2 hours ago," how are you supposed to know if it's rounding the number or giving you an exact value? If it's currently 11:15am, was the email sent before or after your 9:00am phone call? 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)
kellysutton 14y ago
There's a great jQuery plugin that we use at LayerVault to handle this called timeago: http://timeago.yarp.com/ http://timeago.yarp.com/ If you're taking screenshots of things, that's your own prerogative.
pavel_lishin 14y ago
Is it ironic that this blog post only includes the date when it was published, not the time? I wonder if it was before or after that 9am email.
deleted 14y ago
[deleted]
streeter 14y ago
He must hate the dates on Hacker News.
philfreo 14y ago
I like using http://timeago.yarp.com/ http://timeago.yarp.com/ with the HTML5 time tag.
ndaugherty18 14y ago
If you are worried about not knowing when the screenshot was taken couldn't you include in the actual file name the date the screenshot was taken in a "machine readable" format?
- jonhendry 14y ago
  It's more of a problem with screenshots you didn't create yourself.
rane 14y ago
> Twitter has since stopped using relative dates on their tweet pages, and instead just shows the full date now. 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.
jedbrown 14y ago
The archival quality of something displayed on the screen is not as small of a factor as some people are making it out to be. I can't count the number of times a poor user has pasted the output of "hg log" into an email without stripping the sequence number out of the changeset line, only to confuse another mailing list reader when they look for the patch using the sequence number.
dredmorbius 14y ago
Add to peeves: news sites which fail to include bylines indicating one or more of: author/reporter, city/location, date.
machrider 14y ago
Speaking of crappy user interfaces, his blog breaks the Alt+Left keystroke to go back. It takes me to previous blog entries, rather than back to HN. Grrr.
twinsnes 14y ago
I have no problem with relative time stamps. They are conceptually easier for me to relate than absolute time stamps. What does annoy me though is when you have 05-06-12, is that dd-mm-yy or mm-dd-yy?
winter_blue 14y ago
If you push this argument further, missing time zones are a problem as well. I recently moved between continents, and the time zone difference sometimes results in gmail conversation threads showing send times ("On Aug 15 9:00 PM Someone wrote: ...") that appear to time travel.
tommymorgan 14y ago
You should also not override the keyboard shortcut for navigating back (alt-left arrow).
tsieling 14y ago
I think there's room for both relative and absolute. Encode the absolute in the metadata for machine readability and display relative to the people for as long as it makes sense. We can go beyond 'it must be 0 or 1' when it comes to the presentation layer!
ZenJosh 14y ago
My general rule for relative dates is: 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.
fshen 14y ago
I agree with the author. And Absolute are cacheable. It's readable. what's wrong with 2012-08-24 10:16:59?
hcarvalhoalves 14y ago
Just two things: 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>
eranation 14y ago
I completely agree, I always show both, keeps everyone happy.
xutopia 14y ago
It's funny his example is with Twitter screenshots. It's one of those things I hate. Why not link to the real thing instead?
ianstormtaylor 14y ago
The problem is not relative dates in context. Relative dates in context are extremely useful! Would I rather have to parse "4:50pm January 10th, 2012" or "5 minutes ago". --- 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.
- eurleif 14y ago
  >- Listen for print-screen commands and swap things to relative dates. (I have no idea if this is possible. I actually would be that it isn't, but maybe it should be.) 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.
  - ianstormtaylor 14y ago
    Very true. 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.
rohitarondekar 14y ago
Are there any UX or usability studies regarding date time formats to use on the web? I'd be interested in knowing more than this feels right to me. :)
i386 14y ago
I work on a product for software developers and speaking to our customers there are two camps: those who like relative dates and those who like absolute dates. What does HN prefer?
prunebeans 14y ago
Tell me about it. Now my sister hates me, my uncles don't want to speak to me anymore, and my cousins play darts with my pictures...
asmaklad 14y ago
I think the point of showing relative dates is that the web is International and cross border. and if you display a date time. You need to define next to it Which Timezone ! 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. Another Scenario: 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 ?
nathan_f77 14y ago
Relative dates are awesome. They're easier to understand, and save us a lot of space. We use the timeago [1] jQuery library. It shows relative dates in an abbr tag and keeps the microformat in the title attribute, which shows in a tooltip on hover. We use the en-short [2] locale, so it formats times like '1y ago', '1mo ago', '3m ago', etc. 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. [1] http://timeago.yarp.com/ http://timeago.yarp.com/ [2] https://github.com/rmm5t/jquery-timeago/blob/master/locales/jquery.timeago.en-short.js https://github.com/rmm5t/jquery-timeago/blob/master/locales/...
srik 14y ago
One interesting solution would be to have the html contain/display the exact date, so any scrapers etc. have access to the precise date BUT use a Javascript/CSS overlay the relative date on top of that exact date.
cyberpanther 14y ago
I've always hated relative dates. Glad people are finally coming to their senses. The only case I see for relative dates are that they are more user friendly. But is it really that hard to parse "Wednesday, August 22nd at 8:22PM"? While I believe in easy to use interfaces, we don't have to act like our users are total bafoons either. In the long run relative dates are more confusing for screenshots, leaving a page open, etc as stated in the post.
bradezone 14y ago
I totally agree, this is another case of software thinking it's smarter than me. This is really a problem on blogs, where you'll have 5 comments in a row that say "posted 1 hour ago" and you have no idea the order you're supposed to read them. Common sense nullified by "smart" apps yet again...
ikawe 14y ago
tried to wrap up some of the discussion with this rails gist: https://gist.github.com/3471071 https://gist.github.com/3471071

213 points by caseorganic 14y ago

grecy 14y ago

> Now, Twitter uses the format "10:42 PM - 15 Aug 12" Wouldn't including the relevant timezone be even better?

aaronpk 14y ago
That would be very helpful actually! Good point.
- aero142 14y ago
  If you figure out how to do that without it being an account setting option, you let me know.
  - TillE 14y ago
    I'm not a web developer, but can't you do that with Javascript? http://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp http://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/ http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zo...
    - jeltz 14y ago
      Neither of those two solutions are correct. They only work in a some cases. You need a more advanced detection algorithm for this. Preferably one based on the Olson database, since time zones have changed over the years and you want to be able to display past dates correctly. This solution linked from your second link looks more correct. https://bitbucket.org/pellepim/jstimezonedetect/src/e265c8eddec7/detect_timezone.js https://bitbucket.org/pellepim/jstimezonedetect/src/e265c8ed... But still I am not sure if this is the right way to do it.

uranmoron 14y ago

Incredible timing, I was just thinking how irritating this is on Github.

danso 14y ago
And on HN.
jlcx 14y ago
I'm glad I'm not the only one.

jere 14y ago

I think a bigger problem is absolute dates with no year; I've seen this on blog posts and comments (can't remember any examples right now though). 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.

marsvskittens 14y ago
Equally frustrating is when dates are displayed without the weekday, especially when trying to schedule an event. "August 30 2012? Wait, is that a Tuesday or a Wednesday?" Hopefully the <time> element catches on, so I can make my browser display dates however I like.
- untog 14y ago
  Personally I think that's an event only argument. I couldn't care less what day of the week a blog post was written, for example.
  - aaronpk 14y ago
    Great point about displaying event dates. I think there should be some display guidelines based on the type of content the date is describing.
  - MartinCron 14y ago
    That's a good example about why there's no one-size-fits-all approach to displaying dates and/or date intervals. I care what day of the week I fly. I care if someone commented on my picture 2 minutes or two hours ago. I don't care about the local timezone of someone else's server.
jlcx 14y ago
Here's one that has confused me: http://buyersguide.macrumors.com/ http://buyersguide.macrumors.com/
mmcnickle 14y ago
I find a frustrating number of sites don't put any date on their articles/posts. Everything on the web should have a visible date somewhere.

noblethrasher 14y ago

You probably shouldn't hijack the keyboard shortcuts for the back button either. Nice article otherwise.

aaronpk 14y ago
It's supposed to catch the left and right arrows. Didn't notice it also caught the back button! thanks.
- aaronpk 14y ago
  Fixed it!
  - michaelhoffman 14y ago
    Not for me (Firefox/14.0.1 on Windows 7)
  - noblethrasher 14y ago
    I'm afraid not: Chrome21/Win7
    - aaronpk 14y ago
      ok, really fixed it this time
      - noblethrasher 14y ago
        Nice!

jerhinesmith 14y ago

As a sometimes developer of web applications, relative dates nicely (for me) solve the problem of timezones. "10:42 PM - 15 Aug 12" means nothing without the relevant timezone information. "30 minutes ago" is timezone agnostic. For non-commercial apps, lately I've been displaying relative time, but embedding the actual datetime (in UTC) as a title attribute.

foxhop 14y ago
Agree. I prefer "ago" and your suggestion of a title/hover/hidden datetime is an even better idea! recently I published a python module to calculate the ago: http://pypi.python.org/pypi/ago http://pypi.python.org/pypi/ago

dllthomas 14y ago

Rounded dates make it less obvious when you've been posting during work hours...

bryne 14y ago

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.

aaronpk 14y ago
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.
- deleted 14y ago
  [deleted]
- bryne 14y ago
  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 14y ago
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} ?
- bryne 14y ago
  Sure, but that seems harder than attempting to shame developers into changing the way they display timestamps.
  - deleted 14y ago

ars 14y ago

An entire article on dates and not even the slightest mention of timezones?

gshaw 14y ago
This. How can you display a time and mean something if you don't know what timezone the user viewing it is in?
- icoloma 14y ago
  It gets even worse with DST. is GMT+2 meant to be Spain in summer, or something else? Relative dates are a blessing where space is a constraint

nostromo 14y ago

"2 hours ago" is actually more informative than "1:08 PM 23 Aug". The latter requires a location to be exact (1pm where? Is this being localized? Do you guys use daylight savings?) and the former does not.

bobbles 14y ago
Can't we just display both? 2012-08-23 1PM (2 hours ago)
- aaronpk 14y ago
  Yep, Gmail shows both and it works well!
  - arctangent 14y ago
    I concur. I do think the "5 minutes ago" type of message should be shown first, with the detailed date/time in brackets afterward. What the users want/need is probably the key driver in this kind of UX decision though.
- calciphus 14y ago
  Depends where you're displaying it. There's a pretty big clutter-and-space consideration for a time stamp that's 3x longer.
  - devcpp 14y ago
    Send a usual absolute time stamp and let the client compute the relative time, hoping it is accurate.
  - nivla 14y ago
    I think the best way to display date/time is to have the text in relative date/time and title in actual date/time. For example: 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!!

mikey_p 14y ago

So you don't prefer them and that's why I shouldn't do something? 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.

luney 14y ago

I find relative dates to be the most useful, most of the time. The scenarios where needing the exact date or time come less frequently. 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.

Geee 14y ago

The reason why relative dates are used is that you don't have to worry about timezones. You either have to get client's timezone and reformat dates, or use static timezone and let users do the conversions in their heads. 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.

bernardwilson 14y ago

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.

aaronpk 14y ago
Gmail is a great example because they show both the relative date as well as the actual time, so you get the best context.
dredmorbius 14y ago
"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 14y ago
  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.

verisimilitude 14y ago

Here's what I do. First, the markup: <time datetime="2011-08-27T19:15:38Z" pubdate>27 Aug, 2011</time> So, time in [ISO 8601][0] format. Run JS to transform '27 Aug, 2011' into a relative date. If the relative date is >1 month (or, whatever you'd like), then just display the full date. [0]: http://en.wikipedia.org/wiki/ISO_8601 http://en.wikipedia.org/wiki/ISO_8601

cheald 14y ago
Ding ding ding. Machine readable and user-friendly. 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.
- mmahemoff 14y ago
  And cacheable too.
- jonhendry 14y ago
  If it stops one long-since-debunked urban legend from being propagated via a screenshot of an old, relative-dated post, it's probably worthwhile.
jacobr 14y ago
This would even let users change the date back with a user script. 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.

tb303 14y ago

ridiculous argument and bad misinformation. relative dates are better for users in any context involving event freshness/recency, and they are machine readable by using many well-known markup techniques, including the microformat he mentions.

noblethrasher 14y ago

Create an `@media print` css rule that displays absolute date/times (with time zone). That's just about the best of both worlds.

binaryorganic 14y ago

I agree with all the dissent posted here. 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.

nilved 14y ago

Why would you ever use `abbr` with `title` instead of `time` with `datetime`?

cheald 14y ago
<time> is HTML5, which not everyone is on.

gatordan 14y ago

I dislike when an author titles and formats their post in this way. The title is an overstatement about why something that is common practice is wrong ("hey! i use relative dates, what am i doing wrong?"), leading to an article with a couple interesting points, ending with a concession that common practice is actually OK but could be better. 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: ..."

kapowaz 14y ago

This sounds like more of an argument for why you shouldn't be distributing stuff in the form of screenshots (although the horrendous entropy of the web is a compelling argument in favour of that, I realise).

run4yourlives 14y ago

Lot's of love for relative dates, but personally, I agree with the poster. Here's an example from HN: user: run4yourlives 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.

rane 14y ago
I'm afraid HN isn't very notable for good UX in general.
MartinCron 14y ago
The "2012 days ago" is just a sub-optimal implementation of relative dates. It could be expressed as the more comprehensible but less precise "over 5 years ago" with the actual date either nearby or in the title=""
- run4yourlives 14y ago
  Or you could just show me the actual date, since it does everything a person needs it to do already.
- deleted 14y ago
  [deleted]
notatoad 14y ago
Okay, but how is Feb 19, 2007 relevant information to you? If you were trying to schedule something based on your HN Join date, then i suppose you want the actual date. In the general case though, the date on your profile is only used by other members (or maybe moderators) to get a rough idea of how long you've been a member for. I can look at your profile, see 2012 days, and understand immediately that you've been an HN member for a long time. I've learned everything i need to know, and i've learned it quicker than i would have by reading a full date and subtracting it from today's date. 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.

nodesocket 14y ago

This totally depends on context. For example, on HN, relative dates are great, it is much easier to see how old posts are at a glance. However, anything where date is important, use the full representation. 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.

ajanuary 14y ago
8/1/2012 suffers from the dd/mm vs mm/dd problem.

idoh 14y ago

I'm the PM for a horoscopes app, and I much prefer to use relative dates (e.g. yesterday, today, tomorrow) instead of absolute ones (e.g. wednesday, thursday, friday). 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.

csomar 14y ago

If you're looking at an email and it says "2 hours ago," how are you supposed to know if it's rounding the number or giving you an exact value? If it's currently 11:15am, was the email sent before or after your 9:00am phone call? 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)

kellysutton 14y ago

There's a great jQuery plugin that we use at LayerVault to handle this called timeago: http://timeago.yarp.com/ http://timeago.yarp.com/ If you're taking screenshots of things, that's your own prerogative.

pavel_lishin 14y ago

Is it ironic that this blog post only includes the date when it was published, not the time? I wonder if it was before or after that 9am email.

deleted 14y ago

[deleted]

streeter 14y ago

He must hate the dates on Hacker News.

philfreo 14y ago

I like using http://timeago.yarp.com/ http://timeago.yarp.com/ with the HTML5 time tag.

ndaugherty18 14y ago

If you are worried about not knowing when the screenshot was taken couldn't you include in the actual file name the date the screenshot was taken in a "machine readable" format?

jonhendry 14y ago
It's more of a problem with screenshots you didn't create yourself.

rane 14y ago

> Twitter has since stopped using relative dates on their tweet pages, and instead just shows the full date now. 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.

jedbrown 14y ago

The archival quality of something displayed on the screen is not as small of a factor as some people are making it out to be. I can't count the number of times a poor user has pasted the output of "hg log" into an email without stripping the sequence number out of the changeset line, only to confuse another mailing list reader when they look for the patch using the sequence number.

dredmorbius 14y ago

Add to peeves: news sites which fail to include bylines indicating one or more of: author/reporter, city/location, date.

machrider 14y ago

Speaking of crappy user interfaces, his blog breaks the Alt+Left keystroke to go back. It takes me to previous blog entries, rather than back to HN. Grrr.

twinsnes 14y ago

I have no problem with relative time stamps. They are conceptually easier for me to relate than absolute time stamps. What does annoy me though is when you have 05-06-12, is that dd-mm-yy or mm-dd-yy?

winter_blue 14y ago

If you push this argument further, missing time zones are a problem as well. I recently moved between continents, and the time zone difference sometimes results in gmail conversation threads showing send times ("On Aug 15 9:00 PM Someone wrote: ...") that appear to time travel.

tommymorgan 14y ago

You should also not override the keyboard shortcut for navigating back (alt-left arrow).

tsieling 14y ago

I think there's room for both relative and absolute. Encode the absolute in the metadata for machine readability and display relative to the people for as long as it makes sense. We can go beyond 'it must be 0 or 1' when it comes to the presentation layer!

ZenJosh 14y ago

My general rule for relative dates is: 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.

fshen 14y ago

I agree with the author. And Absolute are cacheable. It's readable. what's wrong with 2012-08-24 10:16:59?

hcarvalhoalves 14y ago

Just two things: 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>

eranation 14y ago

I completely agree, I always show both, keeps everyone happy.

xutopia 14y ago

It's funny his example is with Twitter screenshots. It's one of those things I hate. Why not link to the real thing instead?

ianstormtaylor 14y ago

The problem is not relative dates in context. Relative dates in context are extremely useful! Would I rather have to parse "4:50pm January 10th, 2012" or "5 minutes ago". --- 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.

eurleif 14y ago
>- Listen for print-screen commands and swap things to relative dates. (I have no idea if this is possible. I actually would be that it isn't, but maybe it should be.) 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.
- ianstormtaylor 14y ago
  Very true. 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.

rohitarondekar 14y ago

Are there any UX or usability studies regarding date time formats to use on the web? I'd be interested in knowing more than this feels right to me. :)

i386 14y ago

I work on a product for software developers and speaking to our customers there are two camps: those who like relative dates and those who like absolute dates. What does HN prefer?

prunebeans 14y ago

Tell me about it. Now my sister hates me, my uncles don't want to speak to me anymore, and my cousins play darts with my pictures...

asmaklad 14y ago

I think the point of showing relative dates is that the web is International and cross border. and if you display a date time. You need to define next to it Which Timezone ! 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. Another Scenario: 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 ?

nathan_f77 14y ago

Relative dates are awesome. They're easier to understand, and save us a lot of space. We use the timeago [1] jQuery library. It shows relative dates in an abbr tag and keeps the microformat in the title attribute, which shows in a tooltip on hover. We use the en-short [2] locale, so it formats times like '1y ago', '1mo ago', '3m ago', etc. 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. [1] http://timeago.yarp.com/ http://timeago.yarp.com/ [2] https://github.com/rmm5t/jquery-timeago/blob/master/locales/jquery.timeago.en-short.js https://github.com/rmm5t/jquery-timeago/blob/master/locales/...

srik 14y ago

One interesting solution would be to have the html contain/display the exact date, so any scrapers etc. have access to the precise date BUT use a Javascript/CSS overlay the relative date on top of that exact date.

cyberpanther 14y ago

I've always hated relative dates. Glad people are finally coming to their senses. The only case I see for relative dates are that they are more user friendly. But is it really that hard to parse "Wednesday, August 22nd at 8:22PM"? While I believe in easy to use interfaces, we don't have to act like our users are total bafoons either. In the long run relative dates are more confusing for screenshots, leaving a page open, etc as stated in the post.

bradezone 14y ago

I totally agree, this is another case of software thinking it's smarter than me. This is really a problem on blogs, where you'll have 5 comments in a row that say "posted 1 hour ago" and you have no idea the order you're supposed to read them. Common sense nullified by "smart" apps yet again...

ikawe 14y ago

tried to wrap up some of the discussion with this rails gist: https://gist.github.com/3471071 https://gist.github.com/3471071