My preferred date formats

Dates are an important part of business communication. Yet there’s surprisingly little agreement or consistency regarding their format. What’s worse than inconsistency is that they’re often ambiguous, leading to misunderstandings and unmet expectations.

The following describes my personal preferences for date and time formats. By nature they are opinionated, your mileage may vary. I’m sharing my rationale here; it isn’t an attempt at convincing you to use the same.

Note that I focus on conveying information in a business context, not on stylistic considerations for use in prose or official letters.

Requirements

Date formats must be:

1. simple
2. understandable at first glance
3. unambiguous
4. compatible with usage in filenames and other common places

Furthermore, I’m limiting this post to English only. I’ve tried to bring some of them to German, but they just didn’t work right.

Dates

2022-03-25: the standard, also recommended in ISO-8601. Useful when dates must be fully qualified. Also well-suited for filenames because the format is Big-Endian—meaning the elements are listed from most significant (the year) to least significant (the day)—and file browsers usually order by filename, leading to an automatic sorting by date as well.

Month and day are zero-padded; 2022-03-25 instead of 2022-3-25.

The separators are dashes, not dots or slashes. The former is hard to parse when skimming quickly and the latter is incompatible with filenames, where slash is often the directory separator. Also, I do not recommend removing the separators as some people do for filenames; dates become really hard to parse and it’s only saving two characters.

2022-Mar-25: a different variant of the above, with abbreviated month name instead of its ordinal number. Easier to read for humans. But not recommended for filenames since the names of the months aren’t ordered alphabetically, losing out on automatic chronological sorting.

Mar-25: for brevity I sometimes omit the year when it is clearly identified from context. Such as: “We’ll make the decision on Apr-05, please provide all answers by Apr-02 EOD.”

When omitting the year, always use the abbreviated month name (not the ordinal month number) to avoid ambiguity. Don’t do this: “We’ll make the decision on 04-05, please provide all answers by 04-02 EOD”.

2022-03 / 2022-Mar: references a particular month. The repeated year is a bit verbose when used multiple times in close vicinity. Also, despite following the logical Big-Endian order, it feels unnatural to some readers.

Mar'22: used as alternative reference to a month. It sometimes reads more naturally and avoids too much verbosity. The apostrophe is a contraction of the year, similarly to how “I would do” turns into “I’d do”.

On some occasions I’ll drop the year altogether and write only Mar or March. I usually do this in chats or other information communication, but I avoid doing it in documents which are likely to be read after the current year ended.

Note that there is only a single character differentiating Mar-22 (March 22nd) from Mar'22 (March 2022). When there is a risk of creating ambiguity, I revert to the more verbose format.

EOY, EOQ, EOM, EOW, EOD: these stand for “End Of {Year, Quarter, Month, Week, Day}”. The qualifier should be included to remove ambiguity. Some examples: “We’ll plan till EOQ2 and execute in early Q3”, “Results are expected by EOW12”, or “Demand is strong compared to EOY'21”.

For some reason abbreviations for “Beginning Of” aren’t common. I’ve never seen references such as BOY'22, BOW32, BOQ3, BOD.

H1, H2: first and second half of the year. Unless absolutely clear from context, the year should be included to remove ambiguity, such as “2022-H1”. Given its duration of 6 months, it’s quite probable that any document containing such references will be relevant even after the current year ended. Therefore I’d recommend always adding the year.

Since references to H1 or H2 are sparse, I avoid the apostrophe form of the year. Meaning I use “2022-H1”, not “H1'22”.

Times

16:15: my general preference is for zero-padded 24h-format. It is easier to parse, always unambiguous and naturally sorted in file browsers. But I don’t hold that preference strongly. The am/pm-format is shorter and quicker to type, as in “let’s meet tmrw 2-3pm”. I use both formats, but will lean towards 24h-format in documents.

The more common hours-minutes separator is colon. When using dot separator or not using any separator at all, it should be clear from context that it is a time; usually that isn’t much of an issue.

Some examples: 4:15pm, 4.15pm, 16:15, 16.15, 1615, 16h15. They all work fine.

Zero-padded means 09:15 instead of 9:15.

My only ask:

1. Be consistent within the same document or message;
2. Replace 12am and 12pm with noon and midnight;
3. If communicating with people in different timezones, always include that information with the time, e.g. “16:15 CET” or “4.15pm GMT”.

Thanks!