There’s a global standard that works for everyone: 2023-06-27. Use that for all numeric dates, without exception or localisation or even user preferences. Use a dash (
-)
never slash (/).
Here’s the longer explanation...
TL;DR: Never write numeric dates in the local m/d (6/27) or d/m (27/6) forms. They confuse and alienate people because they are ambiguous and can be hard to understand, especially to individuals outside the United States.
The
same applies to the variant including the year
(e.g.
6/27/23
or 27/6/23).
There’s
a global standard that works for everyone: 2023-06-27.
Use that for all
numeric dates, without exception or localisation or even user
preferences. Use a dash (-)
never slash (/).
Here’s
the longer explanation...
Some
parts of the world traditionally write their dates in the form m/d,
e.g. 7/8
would mean July 8th. Most
countries, however, put the day first as d/m,
so 7/8
would mean August 7th.
Dates in that 7/8
form are ambiguous.
As we read them, they cause a “stall”
in our reading and understanding, and we have to stop and solve a
little puzzle to try to work out what they mean before we can
continue reading. There are a few heuristics we apply, perhaps even
subconsciously, to work it out.
The simplest case is when
one of the numbers is greater than 12. Then that one has
to be the day, not the month, and we know for sure which way round it
is. But even in that “simple” case, it’s already stalled our
understanding and caused us to stop and think about the
ambiguity.
For over a third of the days in the year, it’s
even more complex. We have to consider each of the possible dates,
whether they are in the future or the past, and how far
away they are, to work out which is more likely
to be what was meant in the context. Sometimes, we have to make our
guess based on who
provided the data, and indeed on whom
was the intended audience. It is complicated and error-prone.
Using
the 7/8
form for dates is poor
communication.
For this reason, it is a violation of the Google
developer documentation style guide, the AWS Style Guide and
others.
As
noted above, the United States is one of very few countries in the
world where 7/8 would mean July 8th, rather than August 7th.
If you use the m/d form of dates, users within the U.S. may
have no difficulty understanding you. But your choice is exclusionary
towards those who are not based in the U.S, as it makes it harder for
them to understand you.
For this reason, we also consider
the m/d form of dates to be non-inclusive. Some even
call it a microaggression as it is one of the subtle ways in which
those outside the U.S. are frequently marginalized and made to feel
like ‘outsiders’.
Some
may be inclined to respond to the above observations by localization,
showing m/d to some users and d/m to others. However,
users for whom d/m is the norm are constantly inundated
with dates in the other m/d form — by crappy software,
crappy web sites, and crappy people. So much so, that even presenting
those users with their “correct” local form doesn’t help with
the ambiguity — because they still won’t be able to know and
trust such dates unless you fix the whole of the rest of the world
first. They still have to stop and work it out every
time.
Furthermore, those dates, even if localized
correctly for the first user who sets eyes on them, will “leak”
to other parts of the world through cut/paste and screenshots.
So
please do not attempt “localization” of date formats. It just
doesn’t help. And it helps to give the false impression to users
that those d/m or m/d dates are acceptable in the
workplace.
This same logic applies to user preference,
allowing users to choose for themselves between the d/m and
m/d forms. In fact user preference is even worse because the
default setting is often incorrect, exposing users to the wrong
format for their location despite best intentions.
For all
these reasons, I argue that if you localize dates, you’re still
part of the problem.
Thankfully,
there is a simple answer (other
than spelling out the name of the month, which sometimes works).
The global standards including ISO8601 and RFC3339 define a date
format which is unambiguous: YYYY-MM-DD
(e.g.
2023-07-08
for July 8th). It also has the benefit that a lexicographical sort
works correctly.
This is the only acceptable form for
numeric
dates in the modern global workplace. The m/d
and d/m
forms both started to become obsolescent the moment it became
possible to conduct written communication between Europe and the U.S.
in less time than it takes a steam ship to physically cross the
Atlantic. Those legacy local forms should be avoided at all
times.
Because the ISO standard uses a dash (-)
instead of the oblique/slash (/),
it is immediately visually distinct from the legacy local formats.
That avoids the “pipeline stall” caused by those formats, and is
unambiguous and inclusive. It also means they can more easily be used
in filenames.
Some may claim that the YYYY-MM-DD standard
is not familiar to them, and that they have never seen it before. But
the well-known Frequency
Illusion means that actually, after drawing it to their
attention, they’ll realise that it is already very common anyway,
and they are
seeing it often.
Even if that were not the case, the
unfamiliarity will pass.
The inclusivity, and the lack of
ambiguity, will not.
David
Woodhouse <dwmw2@infradead.org>
2023-12-01