While I got also shocked at first by Go's time formatting, is by far the easiest to learn and memorize once you get it.
I completely agree. I've used strftime and the like for years, and I still can't remember %m vs %M without thinking twice about it, at which point I usually just look at the docs to make sure I'm not making a mistake.
By contrast, as soon as I learned the "trick"[0] behind the canonical date in Go, I had it committed to memory, and I haven't needed to look it up once since.
YMMV, but personally, I'd much rather write "Jan" when I want a three-character month and "January" when I want a full month than try to remember that the former is %a and the latter is %A (...or is it the other way around? Time to check... again!)
I tend to prefer ISO-style dates/times myself... and unless the date+time is tied to a location+event (and not always then), store/transmit as UTC. This leads to far fewer headaches in the long run.
I still can't remember %m vs %M without thinking twice about it
The time component is "%H:%M:%S" — it's all capitals, and I always think "her majesty's ship" when I type it for some odd reason. At any rate, that's how I remember it.
Once I work out that time component, then the date falls into place: "%m-%d-%Y".
But yes, strftime's formatting strings aren't memorable.
(I'm also a server-side engineer, so I active try to avoid formatting dates into anything other than ISO-8601…)
Nah, parsing a date is a thing that you do usually (depends on your job) like 1 every 2/3 months at best.
Every time I have to pick up the docs because Is day the 1st or month the 1st? Ms and Ns which number? Timezone?
I think that the decision of golang to use this way is really unfortunate and yet more lazy than people that don't want to learn yet another (useless) thing.
Comments
While I got also shocked at first by Go's time formatting, is by far the easiest to learn and memorize once you get it.
The argument from the issue https://github.com/golang/go/issues/444
It's not really much of an argument, since transforming the sprintf format to Go is a trivial as printing an specific date.
I completely agree. I've used strftime and the like for years, and I still can't remember %m vs %M without thinking twice about it, at which point I usually just look at the docs to make sure I'm not making a mistake.
By contrast, as soon as I learned the "trick"[0] behind the canonical date in Go, I had it committed to memory, and I haven't needed to look it up once since.
YMMV, but personally, I'd much rather write "Jan" when I want a three-character month and "January" when I want a full month than try to remember that the former is %a and the latter is %A (...or is it the other way around? Time to check... again!)
[0] http://golang.org/pkg/time/#pkg-constants
Since MST is GMT-0700, the reference time can be thought of as 01/02 03:04:05PM '06 -0700
Such sadness. Using a reversed month/year date as a "reference" when we have ISO 8601. Much american-centrism.
Otherwise I like the trick, but I'm not sure it scales to locale-specific time formats (whereas strftime does a bit with %aAbBxX).
I tend to prefer ISO-style dates/times myself... and unless the date+time is tied to a location+event (and not always then), store/transmit as UTC. This leads to far fewer headaches in the long run.
The line right above that one is the first cited reference format:
I know, I'm talking about the mnemonic used to remember this date.
The time component is "%H:%M:%S" — it's all capitals, and I always think "her majesty's ship" when I type it for some odd reason. At any rate, that's how I remember it.
Once I work out that time component, then the date falls into place: "%m-%d-%Y".
But yes, strftime's formatting strings aren't memorable.
(I'm also a server-side engineer, so I active try to avoid formatting dates into anything other than ISO-8601…)
Nah, parsing a date is a thing that you do usually (depends on your job) like 1 every 2/3 months at best.
Every time I have to pick up the docs because Is day the 1st or month the 1st? Ms and Ns which number? Timezone?
I think that the decision of golang to use this way is really unfortunate and yet more lazy than people that don't want to learn yet another (useless) thing.