Fuzzy Date

There is a big difference between human-readable dates and computer-parseable date information. People are much better interpreters of variable inputs while most programs pass around a standardized machine format. Since I'm a PHP guy the two formats I'm used to are MySQL DATETIME and the UNIX timestamp. The former isn't that bad, just YYYY-MM-DD HH:MM:SS (24 hours, and hopefully set to the GMT zone). A UNIX timestamp, the bread and butter of PHP's date handling, is the number of seconds since the UNIX Epoch (January 1, 1970). As an example, this post was published at 1354378668 or 2012-12-01 16:17:48 GMT.

Obviously the UNIX timestamp is not an acceptable format for presenting date information to an end user. Also, while MySQL DATETIME is much more friendly it is still difficult to read in some cases. When you're writing code for computers you have to fit within an acceptable format; when you're writing output for a humans the focus turns to usability, or molding the information so it is easy to understand. PHP has some options for this, including a handy date() function that you can transform a utilitarian timestamp into a nice December 1, 2012 4:17 pm (F j, Y g:i a).

We still have a problem. In everyday conversation, verbal and written, you don't reference all dates in a standard format. 'Yesterday', 'in 3 days', or 'last Monday' are all normal ways to communicate days that will trigger understanding more quickly than a more verbose layout. The idea behind fuzzy dates is to present dates in a way that feels like a more natural communication. While in the process of rewriting my activity stream I wanted to use more fuzzy date logic. The following chunk is a summary (I have some more complicated handling for minutes and hours) of my first attempt. One quick note: all dates in my activity stream are in the past, so I only have to worry about one direction in time.

  1. 

  2. current date			today

  3. -1 day					yesterday

  4. -2 days to -5 days		few days ago

  5. -5 days to -10 days		a week ago

  6. -10 days to -20 days	few weeks ago

  7. etc...

There are a few special case... 'a week ago' does not really trigger unless it's truly a week ago. This is not restricted to 7 days but to the passing of a Saturday. Example: an event that happened on Saturday would register as 'a few days ago' on Monday but as 'a week ago' on Tuesday, even though it could also count as a few days passing. This is just one route to take, as one could argue that a week should be fixed at 7 days, not necessarily a calendar week.

After building the first version I started looking around at other systems that use fuzzy time, mainly Github and Twitter. There approach was a lot more interesting and introduced a new factor. When I built the first iteration I was focused on removing numbers to make the date information easier to read, but sometimes people can relate to a date with numbers faster than a few words, especially when they're scanning through a list of events.

  1. 

  2. Twitter's Approach

  3. within the hour			n min

  4. within 24 hours			n hr

  5. same calendar year		D MMM (3 Nov)

  6. further back			D MMM YY (3 Nov 10)

  7. 

  8. Github's Approach

  9. within 24 hours			n hours ago

  10. within a month			n days ago

  11. within two months		a month ago

  12. same calendar year		n months ago

I found two things interesting about their approaches. First, neither were scared to show digits in their representation. '3 days ago' can be easier to understand than my 'a few days ago' and conveys a more exact point in time. The other thing I noticed was how they were different… Github is focused on elapsed time while Twitter is focused on a point in time. I wanted my activity stream to be focused on elapsed so it made more sense to follow the Github approach.

But what if Github's solution is wrong? After all, how many times during the day do you have to check to see what day it is? Whether I'm filling out paperwork or an online form I always need to check to see what day it is at least once. While the application I'm building is a website, which allows a user to easily glance over to the toolbar to gain some context to the date, I don't want to build something that would add that extra step. Assuming that most people aren't completely sure what today is until they check, one can assume that a date that is in the past would be that much more difficult to relate to quickly.

The solution I ended up going with swung in the opposite direction. After all, for me it didn't matter when exactly the event occured but the context and relations that it occured. If something happened at 9am today, then it happened in the morning. If it occured yesterday during the AM hours than it was yesterday morning. If it happened last Sunday, then I display it as last weekend.

My initial approach was close to what I ended up going with but for the wrong reasons. I set off to remove all numbers from the display format to make the dates fuzzy when I should have dug deep, like Twitter and Github did, to analyze how the dates would make sense given their respective intents. My application is to show activity information in a contextual way that would allow people to read and interpret patterns and relationships, and the fuzzy date concept can be molded and fit to this idea. To see them in action, check out the new responsive, fuzzy-date-enabled lifestream here.