4 ms·

The Twitter bug in December 2014 was caused by using %G instead of %Y. So that won't help much. G comes before Y alphabetically, as does almost ant other letter

• userbinator 8y ago
  G comes before Y alphabetically That's irrelevant. There's a comment I made on a discussion about this a while ago: https://news.ycombinator.com/item?id=17059958 https://news.ycombinator.com/item?id=17059958 It's sad that most people seem to put the blame on everything else except the developer --- who was simply not exercising any common sense nor thinking critically. There's a very good reason to how the format specifiers were assigned, and anyone who doesn't notice the pattern (and surprising deviations from it) has no one to blame but his/herself.
  • acqq 8y ago
    But what is relevant is that the manpage explanation is still "precise but misleading": http://manpages.ubuntu.com/manpages/cosmic/man3/strftime.3.html http://manpages.ubuntu.com/manpages/cosmic/man3/strftime.3.h... "The ISO 8601 week-based year (see NOTES) with century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). " It's still misleading in the sense: "do we want ISO standardized year? Hell yeah! We've found what we want." It induces all the wrong reflexes: is ISO datetime "the name of the most standard date format that can't be read wrongly? Yes. ( https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 ) Is it "ISO 8601"? Yes. Do we get "four digit" "decimal" year? Yes. Hm... it's "week-based"? "Well every year has weeks, so I guess it's all right." Has references to some other part of documentation, "that means that the details probably don't matter much here." Etc. The proper documentation would be: "%G (short for "wronG in most use cases") returns the "week-number-based-otherwise-wronG-year" used only for the special number-of-weeks-based calendar representations, according to the ISO 8601 rules for such representations, and it only by accident sometimes looks like the common calendar year. Should not be used unless it's specifically needed to produce such a number-of-week-based calendar. For the details about these calendars see (the reference)." In the later case the "don't touch this unless you know you need exactly this" is explicit. It even gives a good mnemotechnic device for remembering the "wrongness" of using it in most of the cases. Good documentation is really important, even if the "traditional" -n-x users feel some kind of satisfaction in having the most misleading or useless documentation, to the point that when somebody asks some specific question they point to the very man pages which exactly don't answer that exact question (there are many such examples on the web). And I've personally seen exactly these same self-satisfied programmers behaving just like the users they subconsciously (or consciously) mock, that is, being equally clueless, once they are in front of any other, probably even a bit better manual, but for the topics they are not familiar with. Like setting up a darned printer. Being user hostile is never a virtue, and never something that should be supported or explained away.
    • naniwaduni 8y ago
      > (see NOTES) If you skip over this huge red flag, sure. "See notes", "see below" &c. are almost invariably a bad sign: they indicate that there's complexity here that's too long to explain in-line. Reacting to that with "Hell yeah! We've found what we want." is beyond salvation.
      • manicdee 8y ago
        No. What you put in “see notes” notes is the boring technical detail such as how week numbers are calculated and which document or paragraph this particular implementation holds authoritative over conflicting alternatives. What you put in the man page is the clear statement that for example YYYY “week year” should not be used where yyyy “calendar year” would usually be more appropriate: point out the confusing alternatives and which one the unaware reader is most likely to need.
        • naniwaduni 8y ago
          ... overlooking the fact that you aren't sure what it means for a year to be week-based in the first place, since years aren't a part of a week and weeks don't fit evenly into years. Literally the next sentence suggests that %Y is broadly similar, and that %G has exceptional cases: > The ISO 8601 week-based year (see NOTES) with century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %Y, except that if the ISO week number belongs to the previous or next year, that year is used instead. (TZ) (Calculated from tm_year, tm_yday, and tm_wday.) The %Y text, by the way, is much shorter: > The year as a decimal number including the century. (Calculated from tm_year) I find it hard to fault the manual here; the only improvement I can see making is specifying that %Y is the calendar year, and perhaps noting that it is more appropriate when months are used. Of course, speople (e.g. GGP) feel that in this situation some condescension is deserved, and it may be true that what few users would be misled when they really do want to use a week-based year are more than outweighed by those who correctly choose to use %Y instead. The objection to this isn't technical, because the perceived slight isn't technical. But there is a sentiment, more popular in some circles than others, that the user should be respected as a responsible adult who knows what they're doing, that the programmer using the interface is a peer, and that if they aren't, or are operating while impaired, it behooves them to realize this and either sober up or pass the buck. This isn't necessarily true. Sometimes, e.g. if the interface is exposed to end-users in a field for preferred date format on an invoice or something, it's totally inappropriate. But it is a somewhat traditional assumption, especially for ~system-level interfaces like strftime.
  • gpvos 8y ago
    You are not wrong. But everyone is stupid some of the time, and documentation should take that into account.