6 ms·

Personally, when I first read the spec. for time.Format, I thought "well how bleedin' sensible is that?!" The only thing that annoys me is that it isn't in ISO

Personally, when I first read the spec. for time.Format, I thought "well how bleedin' sensible is that?!" The only thing that annoys me is that it isn't in ISO order (I'd have preferred 2001-02-03 14:05:06 ), but all that you need to remember is "2006-01" and the rest just falls naturally into place. I've seen a couple of "complaints" about this over the last few days, and I just don't understand what the problem is. It's logical and neat.

ustolemyname 12y ago
ISO ordering would make expressing time in AM/PM ambiguous, i.e. the format string "2:05PM".
- lifthrasiir 12y ago
  12:34:56 2007-08-09 would work equally, though. (EDIT: oops, no.)
  - ustolemyname 12y ago
    How do I cleanly express single digit minutes? The format string "4 minutes after 12", is unique, but it's not clear that I could turn "34" into "4". Similar for the hour (12 is now 2). That would also break the "Print this exact time in the format you're currently using" method of creating a compatible time format string.
  - fafner 12y ago
    That's not ISO format though.
- tjradcliffe 12y ago
  But why would you want to? FSM intended us to use ISO-8601 dates and nothing else. If you disagree, I'll meet you on 18/06/12 at 2:04 to discuss the issue, although you have no way of knowing what date or time that string actually refers to. We have a perfectly good, unambigious date and time format. It's true that many users are deeply committed to ambiguous formats, but we should at the very least be trying to dissuade them from using them by making ISO formats the default.
- BenDaglish 12y ago
  I messed up - I meant 2001-02-03 04:05:06 , in which case 2:05PM would be format "4:05PM", (or 16:05) . All that'd happen would be the year and seconds swap order in the "123456" format - but as I said, it's a minor quibble.
Shivetya 12y ago
when importing dates and time from small systems it always amazes me how they screw them up... do they just ignore known standards for a reason? (favorite was dropping leading zeroes in an otherwise ISO format)
fafner 12y ago
> and the rest just falls naturally into place No, the timezone string is messed up: 2006-01-02T15:04:05Z07:00 If they had picked 2000-01-02T15:04:05Z06:00 (03 would make more sense but then there would be issues with 12h vs 24h clock) then they could even express ISO 8601 week number and the corresponding year. Something which is not possible at the moment. Although more difficult to remember it would be 52 and 1999. (For the 2006 it is 01 and 2006 not distinguishable)

ustolemyname 12y ago

ISO ordering would make expressing time in AM/PM ambiguous, i.e. the format string "2:05PM".

lifthrasiir 12y ago
12:34:56 2007-08-09 would work equally, though. (EDIT: oops, no.)
- ustolemyname 12y ago
  How do I cleanly express single digit minutes? The format string "4 minutes after 12", is unique, but it's not clear that I could turn "34" into "4". Similar for the hour (12 is now 2). That would also break the "Print this exact time in the format you're currently using" method of creating a compatible time format string.
- fafner 12y ago
  That's not ISO format though.
tjradcliffe 12y ago
But why would you want to? FSM intended us to use ISO-8601 dates and nothing else. If you disagree, I'll meet you on 18/06/12 at 2:04 to discuss the issue, although you have no way of knowing what date or time that string actually refers to. We have a perfectly good, unambigious date and time format. It's true that many users are deeply committed to ambiguous formats, but we should at the very least be trying to dissuade them from using them by making ISO formats the default.
BenDaglish 12y ago
I messed up - I meant 2001-02-03 04:05:06 , in which case 2:05PM would be format "4:05PM", (or 16:05) . All that'd happen would be the year and seconds swap order in the "123456" format - but as I said, it's a minor quibble.

Shivetya 12y ago

when importing dates and time from small systems it always amazes me how they screw them up... do they just ignore known standards for a reason? (favorite was dropping leading zeroes in an otherwise ISO format)

fafner 12y ago

> and the rest just falls naturally into place No, the timezone string is messed up: 2006-01-02T15:04:05Z07:00 If they had picked 2000-01-02T15:04:05Z06:00 (03 would make more sense but then there would be issues with 12h vs 24h clock) then they could even express ISO 8601 week number and the corresponding year. Something which is not possible at the moment. Although more difficult to remember it would be 52 and 1999. (For the 2006 it is 01 and 2006 not distinguishable)