Issue #9794 has been updated by 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 help to ease the tension and close this issue for good.

matz replied on the mailing list, but I don't think the arguments are valid, and I've replied with my counter-arguments:

http://article.gmane.org/gmane.comp.lang.ruby.general/371471

Feel free to weight in, but I think this issue is as clear as day if you read that.

----------------------------------------
Bug #9794: DateTime.strptime() doesn't work correctly for '%s %z'
https://bugs.ruby-lang.org/issues/9794#change-46469

* Author: Felipe Contreras
* Status: Feedback
* Priority: Low
* Assignee: tadayoshi funaba
* Category: ext
* Target version: 
* ruby -v: 2.1.1p76
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
Time.strptime() works correctly:

    Time.strptime('0 +0100', '%s %z').strftime('%s %z')
    => "0 +0100"

But DateTime.strptime() doesn't:

    DateTime.strptime('0 +0100', '%s %z').strftime('%s %z')
    => "0 +0000"

In Rubinious it does work correctly:

    DateTime.strptime('0 +0100', '%s %z').strftime('%s %z')
    => "0 +0100"

This make the RubySL date space fail:

    DateTime#strptime parses seconds and timezone correctly FAILED
    Expected "1970-01-01T00:00:00+00:00"
     to equal "1970-01-01T01:00:00+01:00"

In addition, both C and perl preserver the offset correctly when doing '%s %z'.

So it's very clear DateTime.strptime() has to be fixed.

Patch attached.

---Files--------------------------------
0001-datetime-fix-strptime-s-z.patch (1.94 KB)


-- 
https://bugs.ruby-lang.org/