Avoid presenting dates with only numbers

Posted on January 5, 2024

Takeaways

No matter how well-intentioned we may be in our designs or specifications, it’s likely that users will misread a date
Context drives what date format to present to users. It’s especially important when a website has international users that come from all sorts of different locales
Don’t assume your users will understand what format is used when a date is presented only with numbers, be explicit and label what format is used

This article is part of a series on user interface micro interactions and how they affect the user experience.

How dates are formatted is an often-debated subject, since formatting depends on language, locale, and habits. Even within the same locale, many people disagree on how to write a date.

This issue is more problematic when dates are only written in numbers, e.g.:

10-06-2025

What is this date, June 10th? October 6th? You see the problem this format can cause.

Avoid presenting dates with only numbers

No matter how well-intentioned we may be in our designs or specifications, it’s likely that users will misread a date.

It’s especially important when a website has international users that come from all sorts of different locales.

Be clear in your designs

Wireframes and mock-ups should present what date format to implement per screen. Since the need to present a date may differ per screen, it follows that wireframes and mock-ups show the appropriate information.

Examples of different contexts where a date can be formatted differently: a statement, trip details, and a transactions table

The examples above show a few different ways to format a date.

On the left, is a statement for a service of some sort. The service provided was given on a certain period, identified on the top right of the image. The payment is expected by a specific date, as seen in the center of the image. These dates are spelled out in words, to avoid confusion.
The example in the center is for a trip. The departure and arrival dates here are not only spelled out in words, they also include which day of the week they occur. In the case of a trip, this detail is likely important for the travelers. Note that I used the 24-hour format for the hour; that also could raise discussions, which are outside the scope of this article.
Finally, the example on the right shows a transactions table. In this case, I opted to use a number-only format for the date, as it helps sorting the transactions. Note that I provided a clear label (“YYYY-MM-DD”) to identify what each section of the date means.

Note that the context is what drives what date format is presented to users. Also, the idea is not to be clever or to save space, but always to convey information clearly to users.

Ligatures may affect dates presented only with numbers

A ligature is a joining of two characters into one shape. For example, in French “œ” is a ligature of “oe”.

— “Ligature”, MDN Web Docs

Ligatures happen in many fonts, although not necessarily in all of them.

It may seem a bit of a stretch to mention ligatures in an article about date formats, however I was recently faced with the following issue when trying to fill a form:

A number-only date input which reads '8/½020'

I took this screenshot from a form I encountered on one of the multiple platforms recruiters and human resources (HR) people use to filter out applicants.

This ridiculous date display struck me because that is not what I typed — willingly entering the “½” glyph usually requires me to go out of my way and search for it on Copy Paste Character.

To get to this situation, I opened the date overlay by clicking on the calendar button on the right, selected a date, and this is how the interface formatted the date on its own.

An error message below a date input that reads 'Please use the format m/d/YYYY (e.g. ¼/2024)'

Even more fascinating was when I tried to correct the value, I obtained an error message which showed me that I was expected to use fractions in the input!

I see a few offenses in this design pattern:

The Designers or the Developers chose to enforce a number-only format that align with their locale — likely Americans, as they are known to often use a month-day-year format.
The font chosen by the Designers has ligatures for when certain number glyphs are combined with a slash (“/”), and the Developers did not think to disable the ligatures for inputs and error messages.
Did anyone test their own work to ensure that this situation would not happen!?

Avoid formatting date inputs

Be aware that native date inputs format dates differently per browser

The date format of the native browser date input cannot be changed without a lot of technical effort.

Each browser formats the date differently inside the input field, it even varies on the same operating system (OS)! See a few examples below.

Screenshots of the date input article from MDN web docs for Edge, Chrome, and Firefox on Windows. Each native HTML date input show a different date format. — Date input format comparison on Windows browsers

Screenshots of the date input article from MDN web docs for Chrome, Firefox, and Safari on macos. Each native HTML date input show a different date format. — Date input format comparison on macos browsers

Avoid trying to reinvent the wheel by spending time creating a custom component, or by trying to modify the native HTML input element. Instead, change your mindset and leverage what browsers offer by default and invest your design and development time elsewhere.

Be mindful that this also means you should avoid mentioning an expected date format in the error message for the input, to avoid misleading your users.