# Bug in String.to\_datetime (or... soap4r doesn't parse dates correctly when used with rails) **URL:** \ **Category:** Rails\ **Created:** [August 20, 2008, 1:04am UTC](https://www.ruby-forum.com/t/bug-in-string-to-datetime-or-soap4r-doesnt-parse-dates-correctly-when-used-with-rails/146325 "2008-08-20T01:04:26Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Spock](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7c8e57/32.png) [@Spock](https://www.ruby-forum.com/u/Spock)\ **Post date:** [August 20, 2008, 1:04am UTC](https://www.ruby-forum.com/t/bug-in-string-to-datetime-or-soap4r-doesnt-parse-dates-correctly-when-used-with-rails/146325/1 "2008-08-20T01:04:26Z")
Rails ActiveSupport adds a to\_datetime function to the String class. But, for some reason, it doesn’t handle timezone specifications in date strings, nor does it handle second fractions. For example, one consequence of this is that a standard XML dateTime representation isn’t parsed correctly: ‘2008-08-04T13:10:42.312+03:00’ Would get parsed to the date August 4th, 2008, 13:10:42 PM, in UTC, with no second fraction (which is obviously wrong) I’ve encountered this problem when using the soap4r library with Rails. soap4r looks for a to\_datetime method as a first option to parse dates in SOAP responses (presumably since Ruby 1.9 supports such methods, I’m not very familiar with 1.9). Since Rails provides this for the String class, soap4r uses the Rails implementation, which loses information and provides incorrect dates. I’ve managed to get around this by overriding Rails’ to\_datetime with a method that does it correctly, but this seems like an ugly solution. Anyone know why this is the chosen implementation? It seems to me that implementing support for timezones and second fractions is trivial since DateTime.parse already does that very well… Thanks, Yair Halevi (Spock)