So they appear to be aiming for consecutive numbers:

  Mon Jan 2 15:04:05 MST 2006  (MST is GMT-0700)

  Month: 1
  Day: 2
  Hour: 3 (15 being 3pm, or 03 for 12-hour clock)
  Minute: 4
  Second: 5
  Year: 6 (2006)
  GMT offset: 7 (well, -7)

But this is confusing for anyone outside the US, because the month is 1 and the day is 2. I would probably need to dig out the docs to figure out:

  01/02 03:04:05PM '06 -0700

because of the ambiguous 01/02.

Also having the year consecutively after the time is a little weird.

Seems like big-to-small ISO times (year, month, day, hour, minute, second) might have been a better choice. They're logical and unambiguous, irrespective of locale. And the clear consecutive order helps with memorability. e.g. in consecutive-number order:

  2001-02-03 16:05:06 GMT-07:00

Totally agreed, I like the idea but the numbering scheme really leaves me scratching my head.

Going big to small would be way nicer, especially if that was the standard representation as then you'd get lexical ordering for free within time zones.

I can't imagine these guys made that decision lightly, they are too smart for that, there must be some other background to it.

I agree.

The new format is much more readable but just as difficult to write. I would still need to consult the manual -- or at least copy/paste a working example and modify it.

Still - One might argue that readability matters most. This is especially true in large projects with many developers working on the same code.

I think in European dates, and I think this numbering is fine.

ISO 2014: YYYY-MM-DD format always seemed a nice compromise, so just think of 1 being the first non-year portion.

wait... now developers would have to remember numbers. dumb idea..

The reason we have characters for numbers, in cases where applicable is, its easier to remember/represent with characters. Like URL instead of IP. code will figure out, how to convert string to numbers.

what is the point of having format in numbers? In your brain, you are thinking "I need two/three character month", so I will put 'MM'/'MMM', instead of 'Jan'. In Go's case, I have to remember to use Jan or 01.

Nice try though.

I've never come across this way of laying out the date:

    "01/02 03:04:05PM '06 -0700"

What about correlating the mnemonic digits to period sizes:

    "06/05 03:02:01PM '07 -0400" 

(with timezone offset coming between hours and days)

This would correspond to iso:

    "2007-06-05T03:02:01.0"

I agree, numbering it in order of period sizes would be easier than remembering the arrangement of the canonical form, especially for international users.

(Also, it would be "2007-06-05T15:02:01.0")

I find that I need to lookup the special values when writing Go time format strings. In this regard, Go time formatting is no better than strftime.

The win comes from reading format strings. I find that it's obvious what the format is supposed to do with out looking at the doc.

it is simpler to remeber that those formatting characters.

Let's not forget: go has a very simple way to implement your way of doing things from any pkg, struct. just implement a func (p *SomeNewCoolTimeDate) Format( layout String) as you see fit.