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.

enter image description here

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 20th June 2013 should the timestamp for dates after 20th June 2012 not include the year portion?


9 Answers 9


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).

  • Yes, that makes sense as it makes the jump less obvious.
    – Ben
    Commented Jan 1, 2013 at 15:42
  • There doesn't seem to be any stand-out consensus on what is the best way of doing this from a UX perspective. I'm accepting this answer because I like this way of doing it (it's very similar to Jimmy's answer but a bit earlier). I'm not sure about the 10 months thing; as I comment on Jimmy's answer I would have thought April would make more sense but that's possibly because I'm used to there being a year-change in April with the financial year changing then.
    – Ben
    Commented Jan 4, 2013 at 10:19

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.

  • 4
    The date is often shown in another format for machine-readability: Hover your mouse over "1 hour ago" and you can see the full timestamp in ISO 8601 format.
    – Random832
    Commented Jan 1, 2013 at 19:22

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.

  • 2
    Out of interest why 9? I like this method of doing it but would have thought something like April might be more appropriate?
    – Ben
    Commented Jan 1, 2013 at 15:43
  • 1
    @Ben - I think nine months is the threshold for a user instantly grokking, 'yes, that's last year'. But you might get away with ten or even eleven months. Commented Jan 1, 2013 at 17:02
  • 1
    Nine months is enough time to have a baby, and it should be enough time to get a clue. Commented Jan 1, 2013 at 22:11

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".

  • 1
    But by including the year when users are used to it not being there it makes it seeem like something was done a lot longer ago than it was.
    – Ben
    Commented Jan 1, 2013 at 15:41

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.


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.

  • It is hard for me to imagine how the dark distant future relates to current revenue. So I don't care about this hypothetical visitor's experience.
    – emory
    Commented Jan 2, 2013 at 2:48
  • @emory Yeah, and two digits for the year will suffice forever. A foreseeable problem you neglect is a glitch bound to happen. Commented Jan 2, 2013 at 7:02
  • According to: en.wikipedia.org/wiki/… memory cost $1 per bit. Imagine it was 1960 you were writing a program for people to use in the 1960s. Why would they want to pay $$$ so hypothetical users in 2013 could use the program?
    – emory
    Commented Jan 2, 2013 at 16:02
  • @emory Sure thing, I don't blame anyone but those who decided in, say, 1990, that an upgrade could still wait :-7 But this question seems to be more about when to display the year which is hopefully stored anyway. Let's just say I stumbled upon more than one old site where the lack of posting year did increase the time required to validate the information provided. I don't expect this to happen to SE of course Commented Jan 2, 2013 at 16:08

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+.


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.

  • If a date is in the current year then no year is displayed, which makes sense. I'm questioning whether the seeming jump at the juncture of a new year when every post suddenly gets a year added makes sense from a UX perspective.
    – Ben
    Commented Jan 1, 2013 at 19:04
  • @Ben got you wrongly, updated my answer. Commented Jan 1, 2013 at 19:58

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.