Nobody had requested any tests. It would have been much easier if 7 years ago you had written the two lines of code required to test this. Anyway, I've rebased my changes on top of the latest master, and added some tests.felipec (Felipe Contreras)
Well, I still don't understand what was discussed here, but it seems we have a fix (r45822). Thanks for doing the sensible thing :)felipec (Felipe Contreras)
Nobuyoshi Nakada wrote: > It doesn't seem there is absolute reason that you have to use `Time.strptime`. Why wouldn't I? It does **exactly** what I want: Time.strptime('0 +0100', '%s %z').strftime('%s %z') => "0 +0100" ...felipec (Felipe Contreras)
tadayoshi funaba wrote: > /* Gr. strptime is crap for this; it doesn't have a way to require RFC2822 > ... This has already been agreed: many options in strptime() are not portable, but that includes '%s' as well.felipec (Felipe Contreras)
It don't understand the details of the discussion, but it seems to me Tadayoshi is arguing that dates cannot be represented correctly in "%s %z". If that was the case why did Git chose it as the format to store dates? Shouldn't Git be...felipec (Felipe Contreras)
Ryan Davis wrote: > I'd like to see this escalated to a neutral 3rd party (matz? ko1?) that can evaluate Charlie's code and weigh it against tadf's Japanese argument. Regardless of any final outcome, adding an English explanation would ...felipec (Felipe Contreras)
English. This is an international project, isn't it? Time.strptime('2001 -0900', '%Y %z') This is clearly a red herring. If you want to fix '%Y %z', go ahead, that's no reason not to fix '%s %z'.felipec (Felipe Contreras)
Tadayoshi you are so fucking ridiculous it's not even funny. You reject a perfectly sensible patch that **EVERYBODY** agrees with for NO REASON AT ALL WHATSOEVER? At the very list give a reason. I'm amazed that anybody would make y...felipec (Felipe Contreras)
felipec (Felipe Contreras)06:51 AM Ruby Feature #8460: PATCH: optparse: add `keep_unknown` option