Date Formatting

Date and Time Formatting are an annoyingly cumbersome topic for most engineers and designers. There’s various combinations of date and time that we can show to people and honestly I’ve found there’s a few things that we can do to avoid confusion.

This blog post covers the standard Gregorian calendar involving formatting. When talking about other systems like the Japanese imperial system or the Buddhist calendar then we’ve got a more complicated system in place.

Don’t ever do MM/DD/YYYY (or DD/MM/YYYY)

If we ever plan on internationalizing the format where we show something like 02/04/03 (or 2003) is incredibly confusing. This is the 2nd of April in a more European style, this is 4th of February in the United States. The ISO format of YYYY-MM-DD where things are descending in units of magnitude is the best format for international audiences. I would love if we could all just move to this format but I imagine changing culture’s format on recognizing a date will be hard.

If we need to show a combination, then it’s probably best to use the Month itself in the date string. But if we’re limited on space, then just use the month abbreviation.

Show timezone only when relevant

My favorite issue that I’ve run into is mostly when we’re using internal tools or displaying things to a user who has a history of items. Let’s take an example of a user submitting a series of journal entries into their blog. When we’re looking at the date time for the created at, what should we show?

We could show something simple like May 9, 2019 5:55pm.

In best practice, we should store the timestamp the user created the entry in UTC to avoid having to a do a bunch of timezone math and when searching for things across users we have a consistent timezone format.

This sounds great right? We store the UTC and we convert to the user’s current timezone. Now let’s take this a step further. If they wrote this on the west coast but are now looking at their entires on the east coast, they’ve shifted.

Now the timestamp says May 9, 2019 8:55pm.

Does that still make sense? If you’re in the current timezone it makes sense but historically it’s a bit odd since you didn’t write the blog post to you at 8:55pm but at 5:55pm. So what can we do?

If we store the timezone the user did the entry in, we could do something real simple. If the user wrote their blog post and are viewing their entry in the same time zone, just continue showing 5:55pm. But if they go to the east coast, we could just do a simple timezone comparison and show 5:55pm PST. This covers the case where they’re not seeing any information more than necessary but they see timezones when relevant.

This is also incredibly useful when you have support team that are working across regions. You could show everything in their timezone or you could show things in the timezone relevant to the user they’re working with.

This also works with 24 hour clocks time since timezones are a universal issue across time formats.