A new year is the perfect time for new beginnings. And how better to start a new year than with an
And not just any redesign, a redesign of time itself. More or less. Kind of.
In the fashion of most unsolicited redesigns, I’ve done it quickly, with little to no research, and with no intent to actually accomplish anything. I highly recommend viewing this as a design exercise rather than a serious proposal. Cool? High five.
With that out of the way, let’s proceed. It all started with this:
My statement was controversial because the USA is notoriously the last chaotic hold-out in an otherwise sensible world. At least when it comes to time and units of measurement—America is widely regarded as dense.
The rest of the world is proud of its rational metric system and logical dating scheme. My now public opinion flew in the face of that.
How could America’s wonky dating format possibly make any sense? Well, let’s start by taking a look at the seemingly superior, prevailing format.
Day / Month / Year
Used by almost the entire world, this format is generally regarded as brilliant making a whole lot of sense. You start with the smallest unit and end with the largest. It doesn’t get much simpler.
The day is, temporally, the unit closest to me, and thus the most relevant. It’s followed by the month, which is slightly farther away, and then the year, which is the farthest. A year is bigger than a month, which in turn is bigger than a day. Logical smooth sailing.
But while the day may indeed be the most relevant piece of information in a given date, it doesn’t mean much without context, and the context only comes later. Let’s take a hypothetical event next month: February 18, 2016.
In this glorious date format, it would look like this: 18/2/2016
When I start reading the date, 18 doesn’t really mean anything to me. I understand that it refers to the 18th of a certain month, but I don’t know which. I need to read further to get the context. On its own, this number is useless.
When I read on and see the 2, my mind has to go back and add the context to the 18. The way we’ve designed calendars implies that the day is actually inside the month. That’s the mental model we’ve all adopted.
Consider if someone told you that your car keys are inside the blue box, which is inside the cabinet. Until you hear about the cabinet, you don’t really know where to start. The blue box doesn’t mean anything to you yet.
That’s essentially what this date format does. I need to consider both 18 and 2 to get any information at all.
Month / Day / Year
So yes, America (along with its buddies Belize, Micronesia, and Mongolia) adopted an unmistakably janky format:
It feels like someone took a machine apart and couldn’t quite figure out how to put it back together. There is nothing graceful about this format.
But let’s take that a look at that event again. Now it looks like this: 2/18/2016
Here, when I read the first number, 2, I’m immediately informed that this event is taking place in February.
With or without the second number, I’ve already gleaned some useful information. I might be out of the country in February, in which case I already know I can’t make it.
More importantly, once I reach that 18, I already know what it means. I already know the exact day it refers to. My mind doesn’t have to backtrack. I’ve already opened the cabinet and the blue box is staring me in the face.
This format isn’t pretty, and on the surface it does seem really arbitrary and janky compareed to its pure, logical counterpart. But on closer inspection, it turns out that this format is actually designed for use. It’s objectively better for the way people actually use dates, once you get over the weirdness.
You could say America’s date format was created by designers, whereas the rest of the world’s was created by engineers. See, I told you this would be controversial.
“Ok,” you might be thinking, “that actually kinda makes sense. But why not just put the year before the month and create even more context?”
Well, this is a fine thought you’re thinking, so kudos on that. So far, both formats have shunned the year to the end of the date. I think there’s actually a great reason for this, which I’ll dive into in a moment.
The short answer, though, is that a huge chunk of the world does exactly that.
Year / Month / Day
This date format isn’t very well known to the Anglo-centric world I frequent (even though it’s an ISO standard), but it’s much more widely used than the USA’s oddball format. China, Korea, Taiwan, Hungary, Iran, Japan, and Lithuania have adopted a format that combines the best of both worlds.
Context first. Consistent scoping of temporal units. Beautiful.
This seems like a perfect solution—everything I’ve been asking for. But those who know me well know that I’m not satisfied until a solution is perfect. Or, alternatively: I can always find something to bitch about.
Let’s take a look at that event again: 2016/2/18
Kind of weird, right? Something feels off.
Honestly, did you even get to 2016 last time, or was it obvious?
Most people aren’t living their lives over a year in advance. How many people send out invitations over a year in advance? Even if it’s June and the event is in January, we know it’s January of next year.
Imagine you and I are standing in your living room, and I tell you that your car keys were in your house, in the cabinet, in a blue box. You’d probably wonder why I didn’t just start with the cabinet. Unless you really needed your car keys, I guess.
The point I’m trying to make is that there’s a difference between useful context and useless context, and the year often falls into the latter category. It’s too big in scope to give us any context that we don’t know about—we’ve already inferred it tacitly.
The reason something felt off with this format is that the information you were actually looking for was 2/18, and you had to skip a useless bit of information on the way there. It’s 2016 now, so obviously the event is going to take place in the same year.
Of course, there are instances when the year is important. History books, newspaper archives, things planned years into the future, anything formal, or when you just want to be extra-clear about something. But day-to-day we find ourselves regularly omitting the year.
This is another reason I appreciate the peculiar American format. It sheds consistency and structure in favor of usability. Information is organized in order of importance to the user, rather than importance to the system. It’s like organizing files by most used rather than alphabetically.
That’s my main issue with this format. It starts out with the least important information. While the year provides more instant information than the day, it’s not information you can do much with. It’s too big.
To mitigate this, we could simply omit the year, as we often do with the other formats (say 5/2 instead of 5/2/16). But omitting the first unit could be much more confusing than omitting the last.
For example, if we occassionally omitted the year, 12/2 in this format could mean either 12/2 (February 2012), or 12/2 (December 2 of this year).
With other formats, a date always starts with what you expect—a day with one, and a month with the other. It’s always the same. Consistent and simple. As long as you’re in the same country, I mean. Don’t even get me started with non-universal standards.
All in all, this is an almost perfect date structure. It puts context first and it has linear unit growth, but it’s hard, at least for me, to ignore these issues. So how do we fix it?
The Double Slash Date Format
To create a better date format, we’ll iterate on the one we just discussed.
Remember, the main issues with this format are:
- Since the year is first, it’s too confusing to omit.
- The year is too awkward and useless to add regularly.
We could potentially solve both by finding a non-confusing way to omit the year. While discussing this issue with a bunch of friends, Joseph Moore suggested a simple, yet compelling rule: Slashes are always required, even when the numbers aren’t.
The resulting format is similar to function arguments in some programming languages. It might take a short while to get used to, but turns out to be incredibly flexible.
Consider the event we were discussing earlier: February 18, 2016. In this case you could send an invite to the event as /2/18. One look at the leading slash and you can instantly tell that the year is omitted. In time, you won’t even notice it, and you’ll just know. Now the difference between 12/2/ and /12/2 is much clearer.
There are a bunch of useful ways to use this format.
- I’m planning a trip sometime in 17/3/ (March 2017)
- I’ll be out of the country throughout /2/ (February of this year)
- I published my portfolio on 14/7/11 (July 11, 2014)
- I moved to New York in 10// (2010)
- I’m throwing a crazy party on //17 (The 17th)
It also creates a new informal way of referring to dates.
- Dates such as “the 17th” can become //17 (4 less characters, it’s the future!)
- Months can become /2/ or /7/ instead of February and July.
- Years can be either 2014 or 14//. Yeah ok, this one’s a stretch.
So let’s consider what this new double slash format has to offer:
- It starts with context and puts actual use cases first (like America).
- It has a linear, logical order of temporal units (like the rest of the world).
- It allows for extremely flexible omission for many different use cases.
- It affords a new shorthand for talking about dates.
I know what you’re thinking. This is exactly what we need. Another standard. As if we don’t already have enough trouble distinguishing between American and Everywhere-Else dates.
You’re totally right in the sense that this will never get enough traction, and even if it did, it’s a losing battle. If the metric system didn’t take in the US, there’s no way something like this will be adopted around the world. The best possible outcome, one that’s almost surely out of reach, is to add yet another format to the already muddled line-up, and further confuse the world.
At the same time, as someone who frequently uses the word “oxt,” I’m a big fan of unofficial solutions to issues like these. While many problems can’t feasibly be solved, the fact is that almost everything can be better, and it’s our jobs as designers to envision how.
Joel led Product Design at DigitalOcean. Now he makes GitHub.
He doesn't write often, but when he does, he makes it count.
Sign up below for:
✅ Sneak peaks at upcoming design articles.
✅ Exclusive content and bonus material.
✅ Weekly Q&A with your questions about design, career development, etc.
✅ Access to the archives 🙃