4 ms·

WTF, who designed that format? That's like having a gun where the muzzle points backwards if you forget a step assembling it.

• rdancer 11y ago
  If you use printf-like function without precise understanding semantics, you're asking for trouble. No amount of careful design is going to change that.
  • btrask 11y ago
    Does this apply to every DSL?
    • scintill76 11y ago
      Not necessarily, because a robust DSL can enforce its semantics. When your "DSL" is just a string to the parent language, not so much. (Though modern compilers can emit warnings about obvious printf issues like incorrect types.)
• marcosdumay 11y ago
  Time measuring units are a mess, and there's no way out of it. (At least while we want them to reflect astronomical events.) Do not complain that people who were handed a mess of a problem to solve got a bad API out of it. That's how things go.
• simoncion 11y ago
  Two things: * As rdancer mentions, you must always fully understand printf-style format options before you use them. To do otherwise invites disaster. * What would you have chosen for the four-digit-calendar-year format specifier and the four-digit-week-of-year format specifier? Edit: Notice also that you can add more "y" or "Y" characters to get greater precision, so the existing format specifiers already solve the Y10K problem.
  • krick 11y ago
    I agree with everything you said and don't think this format is bad at all, but regarding your "Y10K problem" note, I actually prefer PHP date format, that is "Y/y" instead of "yyyy/yy". First of, I'm sure you need year far more often than "week year", so the less intuitive encoding for the latter is acceptable and I have to admit that confusing letter case is pretty easy when the result is identical for most of the time (so simple "run it, see if it works" won't help, and that's exactly how everybody does programming). Second, I don't imagine I'll ever want to display last three symbols of the year instead of the full year, and I most of the time don't want to get "0476" instead of "476" — and if I do, I'm actually OK with post-processing for these special occasions. The only thing I actually want is full year format (whatever long it is) or, rarely, short (2-letter) year format (which I actually think is stupid and never use it except somebody specifically asks me to). So while I'm absolutely clear with what "Y/y" does, I have no idea what 'yyy' would do for 4-digit long year or what 'yyyy' would do for 3 or 5 digit long year for that matter.
  • p1mrx 11y ago
    I would have changed the year and day capitalization, so that YYYY-MM-DD produces a standard ISO date. Although, to be fair, strftime() also requires inconsistent capitalization for ISO dates.
• rm445 11y ago
  Even as someone who uses and is fairly happy with ISO week numbers, I think you're quite right. The problem isn't the ISO 8601 calendar - smart people have thought about these things, and it's probably the best decision to let 2015-W53 contain days in 2016 (gaining in return a contiguous calendar of weeks each with seven days). But 'week numbers year' is obscure enough to deserve a noticeably different format letter.
• LyndsySimon 11y ago
  Funny you should mention that - the Canadians used a battle rifle in both World Wars that effectively had just such a defect - the "Ross Rifle". From Wikipedia: > The bolt could also be disassembled for routine cleaning and inadvertently reassembled in a manner that would fail to lock but still allow a round to be fired, leading to serious injury or death of the operator as the bolt flew back into his face https://en.wikipedia.org/wiki/Ross_rifle https://en.wikipedia.org/wiki/Ross_rifle