Formatting Date/Time to Ensure Clarity, esp. with a Global Audience

Depending where you are in the country, as well as world - people depict Date and Time in a variety of manors, which can be highly confusing to other groups.

Let's start with the Time-Format - The 24-hour clock format, also known as military time, is the least ambiguous time format. It removes the confusion related to AM and PM designations, ensuring a clear and concise representation of time, not prone to error of 'was that 1:30am or pm?'. It has the additional benefit of both taking less space and maintaining cleaner appearance in tables - for easier scanning (e.g. 13:30EST vs 1:30pm EST).

Date Format - As you'll see in some examples below, it's easy for someone from the US or UK to misinterpret the others' dates and execute something far too early or late.

Examples of conflicting date and time formats used globally:

Country	Date Format	Time Format	Example
United States	M/D/YYYY	12-hour with AM/PM	5-12-2023 7:30PM
Military (NATO)	DD MMM YYYY	24-hour	12 May 2023 1930
United Kingdom	​DD/MM/YYYY	24-hour	12-05-2023 19:30
Japan	YYYY/MM/DD	24-hour	2023-​05-12 19:30
Germany	DD.MM.YYYY	24-hour	12.05.2023 19:30
Saudi Arabia	DD/MM/YYYY	12-hour with AM/PM	12.05.2023 07:30PM

So if working with a software application whose users span across date/time style borders or cultures, I recommend either following the 'international standard' or something is in no way ambiguous, like the common military format, depending on your audience's language scope.

• In a Military format there is NO mistaking a day for a month, because the month uses letters not numbers. Example: DD MMM YYYY = 05 Jun 2023 (June 5th, 2023). This is a great option if all your users are English speaker for instance. However if the audience cannot centralize around a single language, the spelling would become a problem and you need to revert to the international standard.

• International Standard "ISO 8601" is a standardized format for representing dates and times. The format is that commonly used is ideal for computer standardization, however other formats exist to support improved readability.

Common ISO Methods:

Content Format Example

Date only: YYYY-MM-DD 2023-05-05

Time only: HH:MM:SS 14:30:00

Date and time: YYYY-MM-DDTHH:MM:SS 2023-05-05T14:30:00

Date and time with UTC time zone (zulu) YYYY-MM-DDTHH:MM:SSZ 2023-05-05T14:30:00Z

Date and time with time zone offset: YYYY-MM-DDTHH:MM:SS±HH:MM 2023-05-05T07:30:00-07:00

Date and time with local time zone: YYYY-MM-DDTHH:MM:SSTimeZone 2023-05-05T07:30:00PDT

Example: 2023-05-05T07:30:00-07:00 = May 5th, 2023 at 7:30 AM (Pacific Daylight Time), 7 hrs behind UTC.

Breakdown of the format:

• YYYY: four digit year.

• MM: two digit month.

• DD: two digit day.

• T: Separates the date and time.

• HH: two digits hour using a 24-hour clock.

• MM: two digit minute.

• SS: two digits second.

• TZD(±HH:MM): time zone designator (Z or +hh:mm or -hh:mm) - offset from Coordinated Universal Time (UTC) in hours and minutes.

  • Z for UTC time.

  • +hh:mm for local time zone ahead of Coordinated Universal Time (UTC) (East of UK).

  • -hh:mm for local time zone behind Coordinated Universal Time (UTC)(West of UK).

To improve readability on the UI and contextualize it for users, here are some recommendations:

• 2023-05-05 14:30Z (07:30 PDT / UTC-07:00)

  • Simplify the look by removing unnecessary items

  • Give spacing for easier visualization.

  • Ideally - KEEP Zulu/UTC time, so everyone is on the same understanding across timezones.

  • Also including local time and UTC offset helps users better understand their time in relation to UTC.

  • Note: The time zone name or abbreviation should be in uppercase letters and follow the conventions of the IANA Time Zone Database.

When using Date/Time in Tables - ensure the column is MONOSPACED so all values align for easy vertical scanning. Hope this helped. Cheers.