3 ms·

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 1

by bromley 15y ago

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

nimrody 15y ago
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.
nicpottier 15y ago
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.
tezza 15y ago
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.
RoadRunner_23 15y ago
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.

by bromley 15y ago

nimrody 15y ago

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.

nicpottier 15y ago

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.

tezza 15y ago

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.

RoadRunner_23 15y ago

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.