First, when I talk about relative times (or would dates be more accurate?), I mean these 4 minutes ago, 1 hour ago, etc.
When should they be used? With what degree of precision? Shouldn't it be the user's choice?
I personally do care about knowing about the exact time say, a blog post has been published. But what if others don't and don't mind 2 weeks ago, 2 months ago or even 2 years ago?
In my opinion, relative dates are incredibly helpful (when used correctly). A relative date, such as yesterday, two days ago, last week provides you with more information than 8/9/2011, 8/8/2011, or 8/2/2011. It not only gives you when something happened, but it tells you when something happened in my current context of now.
I have done some design work with this and here is the biggest caveat: some users still want to know the exact date/time. So I like to follow Alan Coopers thought process of "Design for the probable, provide for the possible." That is to say give the user the most commonly needed or useful information, and then provide for them to get into more detailed information that not everyone may want to see. To accomplish this I use a relative date that has a tool tip with the exact date/time on hover. This works very well in a web application environment. You probably could even just swap the text "2 days ago" with 8/8/2011 on hover.
The second thing to consider is that as a relative date moves further and further away it becomes less and less obvious or useful. Is "One Year Ago" 1/12/2010 or 12/12/2010? So the conclusion I would take from this is that you have to be smart about displaying relative dates so that they are helpful. Just like it is easier to determine what 5/12/2010 means as opposed to "One Year Ago," it is also easier to determine what "Two Days Ago" means as opposed to 8/8/2011.
To what accuracy do you need to know what time an entry was posted?
To the second? Maybe if it was posted less than a minute ago.
To the minute? Maybe if it was posted less than 10 hours ago. Why not if less than 1 hour - because comparing times between something 59 minutes old and something 89 minutes old and having the second one approximate it to 1 hour can be annoying. An example is DropBox, which estimates its upload time to the integer number of hours unless it's less than hour in which case it's minutes. So something that takes 1h 59 mins to upload spends half that time still telling me it's taking 1 hour to upload - very frustrating.
To the hour? Maybe if it was posted less than a month ago.
To the day? That's probably as vague as you'd want to go in most cases. Some situations might require month or year, but it's less common.
So the accuracy required fades with time itself. With relative time it's easy to incorporate the required lack of accuracy of the time, according to actually how long ago it was. Whereas an absolute time needs to give more information (more digits) to be useful in each and every situation. And there's certainly no point in trying to round up/down an absolute time (eg to the nearest hour) - as that just creates a misleading impression of accuracy.
I find relative times very useful - but that's just me - I'm only going to try and work out how long ago it is anyway. I have my satnav setup the same way - because most of the time I want to know how much longer my journey is going to be rather than exactly what time I'm going to get there. But if I went to a lot of places where I need to be somwewhere on time, then maybe I'd probably have it the other way round.
So that's the thing, some people like it, some people don't. If you can provide a setting that switches it like on my satnav then great!
I would add that relative time works internationally, everywhere in the world at the same time where as exact dates can be in different formats and timezones, and I know I'm endlessly trying to work out whether some dates are in dd/mm/yy or mm/dd/yy or whatever other format.
