ISO 8601 and the Date Cult I Happily Joined

Hi, my name is Ken, and I write my dates as 2026-05-12.

I did not always do this. I was raised, like most people, in the chaos: 12/05/2026 in Scotland, 05/12/2026 in America, the same nine characters meaning two completely different days depending on which side of the Atlantic the spreadsheet landed on. Much like when my father visited last week and helped me put up a TV, and I read a measurement in inches and he put it up in centimeters, sometimes these kinds of issues are a lot worse than a few holes in a wall, however.

One day I saw YYYY-MM-DD, and the scales fell from my eyes.

The conversion moment

I posted something innocent on Threads the other day and people had thoughts. Apparently dates are a contentious and controversial topic.

The replies fell into two camps. Camp One: enthusiastic agreement, often in the form of someone confessing they have been quietly renaming their personal files 2024-11-03_invoice.pdf for years and assumed they were alone. Camp Two: passionate defence of DD/MM/YYYY (mostly Europeans) or MM/DD/YYYY (mostly Americans, with a tone usually reserved for constitutional arguments). There were also folks who just responded with a vomiting GIF, so that was nice.

Why YYYY-MM-DD wins

The case for ISO 8601 is almost embarrassingly practical. There are three arguments, and they all matter at the same time:

1. It sorts correctly as plain text. This is the main one for me as a data scientist often dealing with messy data. Drop a folder of files named 2024-01-03_notes.md, 2024-11-12_notes.md, 2025-02-04_notes.md into any file manager on any operating system and they line up in chronological order with zero configuration. No regex, no parsing, no “sort by date modified” that lies to you when you copy the folder. The string is the chronology. This is the single feature that, once you experience it, you can never go back from.

2. It is unambiguous. 2026-05-12 can only mean one day. You do not need to know who wrote it, what country they were in, or which spreadsheet locale was active at the time. The format encodes its own decoding key.

3. It is international. ISO 8601 is the agreed standard. Every major database, every programming language, every log file, every API timestamp, every git log: they all already use it under the hood. We humans are the only ones still arguing about it on the surface.

Notice that none of these arguments are aesthetic. I am not telling you ISO 8601 is prettier (although it is). I am telling you that it is the only date format that does not actively fight the systems you are putting it into.

The cursed alternatives

MM/DD/YYYY is, with respect to my American friends, imperial nonsense. It puts the units in middle-endian order: medium, small, large. There is no other context in which we write numbers like this. Nobody says it is half-past forty-five seven. The format exists because of how Americans say dates aloud (“May twelfth, twenty twenty-six”), which is a fine reason to speak that way and a terrible reason to write that way.

DD/MM/YYYY is locally sensible and globally fragile. It is what most of Europe uses and what I grew up with. The logic is fine: small to large, day to month to year, like writing an address from the house number out. The problem is that the first half of the year is indistinguishable from the American format. 05/06/2026 is either the 5th of June or May 6th, and the only way to tell is to ask the author, who is now on holiday. The worst part is that everyone assumes its in the format they're used to, so I often read that as DD/MM/YYYY while my colleague would see MM/DD/YYYY, causing a month difference. It's infuriating.

Month names (12 May 2026, May 12, 2026) solve the ambiguity at the cost of throwing away machine-readability and adding language-specific ceremony. Lovely on a wedding invitation. Useless in a filename.

And then there are the truly cursed entries: YYYY/MM/DD with slashes instead of hyphens (close, but the slash breaks filenames on Unix), DD-MM-YY (dashes and two-digit years, choosing pain on both axes), and the still-occasionally-spotted DD.MM.YYYY (functional, but let's just stick to the standard when there is no functional difference, please?).

Stakes both tiny and weirdly real

Dates are trivial when you are writing a note to yourself but not when:

• You're writing code in Python and a pandas read_csv guesses wrong about a date column and silently rotates 12 months of your data by 30 days.
• Two analysts in two countries email a spreadsheet back and forth and one of them is now using June where the other meant January.
• You have to look at a CSV from 2017 and figure out whether the day Excel parsed it on was a Tuesday in your locale or theirs.
• A backup script orders files by name and you discover, six months too late, that “newest” meant alphabetical.
• A medical record, a court filing, or a customs form rides on which of two interpretations the recipient picked.

None of these are hypothetical and are problems happening daily as seen on many public news stories in the last decade. The fix is “use the format that does not have this problem.”

Good standards disappear

Here is the slightly sincere bit, the half of this post that is not joking.

Standards are civilisation’s hidden infrastructure. The ones we notice are the broken ones: the power socket that does not fit, the dongle you cannot find, the file your colleague cannot open. The ones that work disappear into smoothness. You do not think about SI units when a recipe calls for 200 grams of flour. You do not think about USB-C when your phone charges. You do not think about TCP/IP at all, ever, which is exactly the point.

ISO 8601 is one of the good ones. It works so consistently that you stop seeing it. git log dates, kubectl timestamps, every JSON API in the wild, every database created_at column: they are all already speaking it. The only place the format is still visible is the human layer, where we cling to regional habits out of muscle memory.

That is what I find weirdly satisfying about the conversion. Adopting ISO 8601 in your own writing is not really about dates, it's about agreeing to live one small layer closer to the systems you already trust to do everything else for you.

An invitation, not a sermon

I am not going to tell you you must convert. The standard does not need me to recruit for it; it has the entirety of computing already on board, doing the work quietly in the background. The path is open. Your filenames are waiting. Your future self, looking for a document from August, will thank you when the folder is already sorted.

If you do convert, you will know it has taken when one day, unprompted, you write the date on the top of a piece of paper as 2026-05-12 and feel a small, illegal kind of joy. Welcome. The timestamp is true. The standard welcomes all.

(Yes, there are extensions. YYYY-MM-DDTHH:MM:SS+00:00. Week numbers. Ordinal dates. Durations like P1Y2M10D. I love them all. That is a different post. Possibly written entirely in UTC.)