Unpopular opinion: Go time format strings are not so bad after all
Go is certainly a biased language, and that's a good thing. Languages that try to be everybody's darling usually end up as feature behemoths with a bloated spec, slow compilers, and projects that are basically write-only.
One of Go's peculiarities has been (and continues to be) criticized as being completely unclear, which is quite the opposite of what Go generally aims to achieve (and, for most part, succeeded in achieving): clarity. Go is a powerful language, yet its syntax and semantics are clear and beginner-friendly. It is one of the few languages that enables juniors and seniors work side-by-side on a project without feeling like an impenetrable jungle to the former nor like a unusable toy languages to the latter.
Where was I?
Uh, yes: Go's time formatting. It's quite peculiar because the ages-old UNIX canon of time format strings goes like this:
YYYY-MM-DD hh:mm:ss
Here, the elements of a time string are represented by letters, and the combination of letters: YYYY stands for a four-digit year like 2024, YY for the two-digit version “24”. “MM” is the two-digit month, “MMM” is the short month name like “Mar”, “mm” is the minute in two digits, and so on. (The actual interpretation may vary between different datetime libraries, but you get the point.)
Go is different.
A time format string in Go may look like
"2006-01-02T15:04:05 -07:00:00"
or
"Mon Jan 2 15:04:05 MST 2006"
This does not look too bad for a format string, but the aspect that is being criticized so often is that the actual numbers, the values in these format strings are crucial for making the format string work.
The time package tries to explain the rules:
// We stress that one must show how the reference time is formatted,
// not a time of the user's choosing. Thus each layout string is a
// representation of the time stamp,
// Jan 2 15:04:05 2006 MST
// An easy way to remember this value is that it holds, when presented
// in this order, the values (lined up with the elements above):
// 1 2 3 4 5 6 -7
To clarify, to build a valid time string, you must use “Jan” or “01” to represent the month, “2006” or “06” to represent the year, “03” or “15” to represent hours in 12h or 24h format, respectively, and so on. "Wed Dec 7 05:32:17 MST 2024" is not a valid time format string.
To make this more confusing, the standard representation is the US-American format - “month, day, time, year, time zone”. Other parts of the world would prefer “day, month, year, time, time zone”. An unambiguous format that is understood worldwide strictly goes from “large” to “small” units: “year, month, day, time (24h format), time zone”.
Anyway, here is my unpopular opinion: All the criticism revolves around constructing a Go time format string. You have to keep remembering (or looking up) what value represents which part of a date/time value. On the other hand, reading a Go time format string is easy and quite straightforward:
"Mon Jan 02 15:04:05 -0700 2006"
"Monday, 02-Jan-06 15:04:05 MST"
"2006-01-02 15:04:05"
Just from looking at these strings, it is clearly visible how a formatted time value looks like, innit?