When should a year be added to a timestamp?

Question

Stack Exchange uses relative timestamps to indicate when an action occurred; a question was asked, edit was made etc. This is done as far back as "2 days ago"; anything prior to exactly 48 hours ago uses the full timestamp. If the timestamp is not in the current year it includes the year.

However, with the advent of a new year this seems to create a dissonance between dates, which occurred exactly two days ago as they jump from "2 days ago" to last year.

This screenshot was taken at 13:23:55 (UTC). I used Stack Overflow as it has the most questions but it's true for all Stack Exchange sites.

As 2012 was last year the year has been added to the timestamp, which makes it seem, to me, that the question was asked longer ago than it actually was.

If there's no need to include the year is it more understandable for a user to not see it? I.e. if it is the 20^th June 2013 should the timestamp for dates after 20^th June 2012 not include the year portion?

Answer 1

Your proposed solution also introduces a jump. If it's 20 June 2013, and I see a post dated “22 June”, I'm going to think “June this year”, and then do a double take because that's still into the future. When it's June 2013, all posts from June 2012 should be marked “June '12”. As the end of the month approaches, it may be good to mark posts from July as being from the past year as well.

I think anything from keeping the previous calendar month yearless to keeping the past 10 calendar months yearless would be reasonable. That way, “Dec 29” still looks like a recent date in January, but a post that's 11 months old has the added year as a mark of age.

Unix (I know, not a common reference in a UX context) does something like this when showing file times: files dates in the last 6 months are displayed with month, day, hour, minutes while older files and dates in the future are displayed with year, month, day. This has the downside of making exactly-6-months-back a jump, I think it would be better to align the jump with a calendar month change.

Not that it's a big deal — whatever you do, there's a jump (from X days ago to a calendar date).

Answer 2

Website should always include the year in title. This is to set a non-confusing standard for everyone. It is also important for crawlers and web scrappers since the full UTC date can be easily transformed to a timestamp with a single method call, where machines can understand it.

Answer 3

Include the year once nine months have passed.

You don't want to include the year when it's inferred, as it's generally a bad idea to increase noise without an increase in signal, particularly when that noise takes a datestamp above the ten-character scale of a single fovea fixation. That reduces scan-ability, which might be a detriment in certain usecases.

That being said, whilst users can tell that '12 September' means last year on the 3rd of January, it might take a little more mental wrangling to realize that something labelled '13th August' is from the future on the 4th of Auguste. It's much harder to exactly tell if a date is forwards or backwards than to take a look and get a feel for its 'general' position in the calendar.

That's why you should include the year specifier after 9 months, rather than the whole 12.

Answer 4

In the case of the SE example, I don't see a huge problem with this. It's not like it's telling you the post was made "a year ago" vs. just a few days ago.

As long as you're leaving the date/time on a post rather than insisting it's just 'a year ago", 90% of folks will be smart enough to figure out it's recent, and the remaining 10% don't care.

If you want to be pedantic and fix this, it'd be trivial to say "anything posted within the last week should use relative timestamps, and everything after that gets dated".

Answer 5

You really shouldn't have to make your users think too much. It may be obvious now, but in the middle of the year (say, April), will it really be obvious that "March" means "a month ago" and "May" means "a year ago"? Even worse, what if it is April 15 and you see "April 16th"? (this can be avoided by doing it month-wise, though) It's even more confusing, especially for people like me who don't keep track of the exact date at all times. This system requires the user to think for a second at times. And, we all know that a central pillar of usability is "Don't Make Me Think".

On the other hand, the current system is creating a slight confusion only around January, when 2012 has just passed. In February, the December post will be from a while ago.

Answer 6

The moment you state a date instead of an elapsed time (where 48 hours do really seem to provide a good boundary), the year should be mentioned. Why? Just imagine in the dark distant future a mirror that didn't know about your smart-date-adjuster(TM) becomes the only available source, with no information on the actual crawling date.

How should a visitor now know whether the information provided stems from a < 12 months time period or not? The information could be hopelessly outdated or still pretty useful, but without a useful date that is more difficult to determine.

Answer 7

Trying to think through all the ways to do this and what makes sense to me...(I'm sure if everyone chimed in, there would be thousands of different suggestions)

I guess what I would prefer most would be to bump the relative timestamps to 30 days and then show a full date thereafter. Seeing "2 hours ago" or "10 days ago" is great. And then when I see a date, I don't even have to read it to know that the item is 30+.

Answer 8

I think we're ok with years, I mean we're all filling papers with dates, and these dates are fully formatted and we can pretty quickly understand the difference between january (a start of the year) and december (it's end), so, I think that adding some unclear rules, like skip 6 (or 9?) months before adding a year, will just increase complexity. Keep things simple: current year only is printed without a year.

Answer 9

Just to bring in an example of a real-world program that does it differently, the ls command draws the line at six months. It doesn't seem to be an exact six months on my system, probably for ease of calculation:

-rw-rw-r-- 1 random random 0 Jul  3  2012 2012-07-03
-rw-rw-r-- 1 random random 0 Jul  4 00:00 2012-07-04

And it immediately switches to including the year again for any future timestamps:

-rw-rw-r-- 1 random random 0 Jan  1 00:00 2013-01-01
-rw-rw-r-- 1 random random 0 Jan  2  2013 2013-01-02

(The YYYY-MM-DD portion is the filename, in case it wasn't obvious)

In this case, the same transition is used to stop showing the time of day, since it occupies the same space as the year. This keeps the date stamp within ten characters (excluding spaces, twelve with) for both formats for easy readability.