I Made Peace with Go's Date Formatting

Image credits: Claudio Schwarz

Three years ago (OMG, time flies), I was invited on a three-month journey to teach Go to people with varying levels of programming experience. In those three months, we covered everything, from the basics to building production applications. I expected lots of tension around pointers, error handling, and concurrency, but somehow, one of the students’ frequent points of frustration came up to be date formatting in Go.

I can’t blame them. I remember my first encounter with it. Coming from years of Java and Python development, I was expecting the familiar comfort of yyyy-MM-dd HH:mm:ss. Instead, I was greeted with something that looked like a mistake: 2006-01-02 15:04:05.

My initial reaction was predictable. “What kind of BS is this?” I muttered, reaching for StackOverflow to find the “proper” way to format dates in Go. But there is one thing I’ve learned about the language over the years: when something feels weird at first, there’s usually a deeper reason worth exploring.

The Honesty Check #

Let me ask you something: when was the last time you wrote a date format string from memory without googling it?

Not the basic yyyy-MM-dd—I mean anything slightly more complex. When you needed to display “Tuesday, January 2nd, 2006 at 3:04 PM EST,” (yeah, it exists) did you confidently type EEEE, MMMM d'rd', yyyy 'at' h:mm a z without a single trip to Stack Overflow or ChatGPT?

Of course, you didn’t. None of us do.

Even after decades of Java development, I still find myself googling “java date format string” for anything beyond the most trivial cases. Is it EEEE or EEE for the full-day name? Does MMM give me “Jan” or “January”? Is it h or H for 24-hour format?

For generations, we have somehow all collectively agreed to pretend that yyyy-MM-dd HH:mm:ss is “intuitive” when what we really mean is “familiar.” But familiar to whom? And at what cost? It feels like an anachronism, a piece of tribal knowledge that someone invented many years ago, to spare an archaic CPU’s processing power. Meanwhile, machines write entire applications, with barely any human supervision. The last thing we want is for them to write code we’re unable to comprehend.

The Google Test #

So if we’re going to google it anyway—and let’s stop pretending we don’t—why not choose the syntax that’s immediately readable when we land on that Stack Overflow answer?

Picture this: you’re scanning through code (maybe your own from six months ago), and you see this line:

What does this produce? You have to decode it. Four E’s means… full day name. Four M’s means… full month name. One d means… day without padding. The mental parser kicks in.

Now compare it to this Go equivalent:

What does this produce? Exactly what it says. No decoding is required. No mental lookup table. No “Wait, is that four M’s or three?”

The glanceability factor here is huge. When you’re skimming through code during a review or hunting down a bug, Go’s format strings don’t slow you down. There’s no mental gear-switching from “decode the symbols” mode to “ understand the intent” mode. You just read it like prose: “Oh, this formats dates as Monday, January 2nd at 3:04 PM.” Done.

Beyond the Syntax #

This shift in perspective changes everything. We’ve been optimizing for the wrong thing. Instead of optimizing for “ consistency across languages” or “compact syntax,” Go optimized for the actual developer experience: reading code months later and immediately understanding what it does.

The format string becomes living documentation. This helps reduce the feedback loop between intent and understanding.

Despite their initial grunting, I watched my students pick up Go’s date formatting in minutes, while the same folks would struggle with traditional format strings for weeks. That’s not because they’re not smart enough—it’s because the traditional approach has an inherent learning curve that Go simply eliminated.

Making Peace #

Honestly, if we’re all going to google it anyway, we might as well google something that makes sense.