Varying Date Format Display

15 Dec 2011 - 6:24pm
1 year ago
5 replies
1263 reads
jodeallen
2011

Has anyone run into a similar problem as described below and come up with any good solutions?

I'm working on a project where we frequently display a list of objects by date from newest to oldest. the Date/Time is part of the display and we generally use the DD MMM YYYY (e.g., 15 Dec 2011).  We have made the display of this format flexible to display only the relevant part of the date to decrease cognitive load as well as a space saver. The algorithm being used is:

  • if object < 1 day old display format (24:MM)
  • if object > 1 day old and < 1 year display format (DD MMM)
  • if object > 1 year old display format (MMM YYYY)

 

This could result in output like this (assuming current date is 15 Dec 2011 13:30):

 

  1. Order 13:22
  2. Order  09:32
  3. Order  08:15
  4. Order  14 Dec
  5. Order  14 Dec
This tends to work fine when there are lots of orders in a short period of time and the user is typically only looking at a window of time less than 48 hours old. 
Display consistency starts breaking down as the timeframe for the data becomes longer and particularly as the number of data points becomes more sparse.
  1. Order 13:22
  2. Order  09:32
  3. Order  14 Dec
  4. Order  3 Apr
  5. Order  Nov 2010
There may be a particular problem in an edge case like this where the data points are not quite a year apart:
  1. Order 14 Dec
  2. Order  24 Dec
The older date could actually look like it comes in the future.
This problem tells me that the algorithm for varying the display format needs to be a little more complex than the one described above. However, several of the ideas we have tried tend to have equally problematic tradeoffs.
One option is to just go with a mm/dd/yyyy or dd/mm/yyyy format (nice debate there) but I would really like to stick to the less ambiguous DD MMM format.
Any thoughts on this problem?

 

Comments

16 Dec 2011 - 3:40am
Larry Tesler
2004

One possibility:

  1. Order at 13:22 today
  2. Order at 09:32 today
  3. Order on 14 Dec '11
  4. Order on 03 Apr '11
  5. Order on 07 Nov '10

These are about 6 chars longer than the longest in your main proposal, only 3 chars longer if you omit the prepositions that I added to aid human parsing.

They are roughly the same length as each other.

They retain the DD MMM format.

They are unambiguous if the reader knows today's date.

Since this is a transient report of orders and not a permanent repository of birth dates, abbreviating years does not cause a Y2K or Y21C problem.

Larry

 

 

16 Dec 2011 - 11:32am
jodeallen
2011

Good points, Larry. Much appreciated!

Jode

16 Dec 2011 - 11:34am
Kivi Shapiro
2007

Another possibility, not inconsistent with the first:

Instead of cutting over from DD MMM to MMM YYYY (or MMM 'YY) after a year, do it sooner, say after six months.  Are exact dates in April 2011, for instance, still important?

On a related note, if you do go the route of using the full date, you can eliminate ambiguity by using ISO 8601.

Kivi

20 Dec 2011 - 1:55am
Sridhar
2010

I have a basic question... does the user of the system need the date and time "when the order was placed"? or does the user require the "duration since the order was placed"? 

25 Jan 2012 - 2:06am
Sridhar
2010

I came across the same situation in my project... I am thinking of using the following rules -

  1. Same day - HH:MM
  2. Prev day or lesser - DD MMM 
  3. Prev year or lesser - MMM YYYY

Thus in the case stated by Jode of 14 Dec 2011 & 24 Dec 2010, the above logic should display -

  1. Order 14 Dec
  2. Order Dec 2010

Syndicate content Get the feed