I'm French and I don't have a lot of experience translating an app in Chinese or Arabic, for example, so take the following tips with a grain of salt in this kind of context. Feel free to contact me if necessary!

Displaying a date is extremely common in digital products, but using a clear format requires a few more considerations.

Here are just a few examples of what is possible:

• DD-MM-YYYY → "06-04-2022"

  • Format commonly used in European countries (or its variant DD/MM/YYYY)

• MM-DD-YYYY → "04-06-2022"

  • Format used by the US, which puts the month first, while the European version puts it second 😵‍💫

• YYYY-MM-DD → "2022-04-06"

  • As defined in the ISO 8601 standard

• DD Month YYYY → "06 April 2022"

  • Display the month in text

• DD Mon YYYY → "06 Apr 2022"

  • Shorter variant of the previous example
• And many, many, many more…

Almost any programming language has a powerful API to format a date however its developer wants.

Thus, it's easy to use a dozen different formats in a single app if you don't set strict standards and conventions. Moreover, some formats work for some countries but not in others.

To simplify and clarify things, I highly recommend to only use two formats in the applications I work on.

Data-first: YYYY-MM-DD

For technical, compact and/or dense data, I use the ISO 8601 version: YYYY-MM-DD → "2022-04-06".

Why?

• This is the only format that can be sorted alphabetically, which is handy for file explorers or data tables

• There is only one way to read it: the year first, then the month and finally the day

  • When using the most common alternatives DD-MM-YYYY or MM-DD-YYYY, you cannot tell if the month or the day is first, except by looking at the current language of the app (and you can still be wrong if you cannot distinguish if it's British or American English)
• The - symbol works everywhere, while / can be refused by some (old) filesystems

Note: I always advise to prefix single-digit months and days by 0 so the format keeps an equivalent visual weight and is easier to parse: 2022-01-01 instead of 2022-1-1

Human-first: DD Month YYYY

For dates supposed to be quickly read by humans (in an article or a blog for example), I prefer to use DD Month YYYY → "06 April 2022" (with the full name of the month and not a shorter form).

Why?

• There is no confusion with this format (the day is two numbers, the month is written in plain text, et voilà)
• It's extremely clear and quick to read: you don't have to convert the month number to its actual month name
• It works in all countries
• It's easily translatable

Finally, if you only want to display a month (in a dropdown for example), I recommend to always show both the month number AND the month name: 01 - January instead of January or 01.

That way, you can visually search for or type the month name or number, and match any input you have at hand (eg. a credit card's expiration date).

Kevin Systrom:

[…] I want to point out that when we launched Instagram, it was a filter app first for everyone. Most people didn’t even know that there was a network behind it. It was a filter app. My intention was always for it to be a social app, and I was bummed when everyone talked about it as a filter app.

But what I realized in there is that the best networks are first to utility, and then they piggyback on that utility, and they become a network. I think Facebook’s actually a great example of this. It may not be so clear, but it was clearly just a directory at the beginning. It was about finding people, communicating with them. And then it became the social network that it became once they added the news feed and all this other stuff.

So Instagram and Facebook are actually not that different in their evolution. [We decided] when we talked about launch, that we were just going to focus on the utility part of it first and be really good at that because starting a social network from scratch, I think, is the wrong order.

You see a lot of people launching things today that are social networks first and then utility is questionable. And it’s because the utility in the social network only makes sense when you’re at scale, when you have a lot of people. And it’s very hard to bootstrap that.

(Emphasis mine)

Today¹, I learned that that you could use a / alpha value in CSS color property functions (hsl, rgb, etc.).²

It looks like this:

color: hsl(0 0% 0% / 0.5);
color: rgb(0 0 0 / 0.5);

Where the alpha value is a number between 0 (full opacity) and 1 (no opacity).

Previously, you had to use a function variant to change the alpha:³

color: hsla(0, 0%, 0%, 0.5);
color: rgba(0, 0, 0, 0.5);

(Note the a at the end of each function, ie. rgb → rgba.)

This is really handy, because you can change the content of the function without changing the function name itself. Which is more practical when using React and CSS-in-JS libraries. I know I would have use that a few times already if I was aware of this small spec change.

The support is pretty good (more than 92%), so it's mostly safe to use on modern websites.