Issue #10677 has been updated by Ben Johnson.


Akira Tanaka wrote:
> There is no direct issue.
> 
> It is inspired by [Bug #9794].

I'd also like to add that Parker's post, and the explanation in the bottom half, is spot on ( [[https://byparker.com/blog/2014/ruby-2-2-0-time-parse-localtime-regression/]] ).

I have a strong feeling this is going to be a **major** problem as people try to move forward. Adding "local" time everywhere you use Time.parse simply is not feasible. This change is also outside of the scope of a "minor" version change for ruby.

Finally, the amount of dependencies a typical ruby project has (gems). There is so much of this behavior we can not control. I can't even think of a backwards compatible patch, as gems start to adopt this new behavior, I'm not sure how we'd distinguish the "before" and "after" gems.

----------------------------------------
Bug #10677: Regression: Time#parse no longer automatically converts to localtime
https://bugs.ruby-lang.org/issues/10677#change-50780

* Author: Parker M
* Status: Rejected
* Priority: Normal
* Assignee: Zachary Scott
* Category: lib
* Target version: current: 2.2.0
* ruby -v: ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin14]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
In Ruby 2.1 and before, `Time#parse` automatically converted to the localtime:

Ruby 2.1:

~~~ruby
>> require 'time'
=> true
>> ENV['TZ'] = 'Australia/Melbourne'
=> "Australia/Melbourne"
>> Time.parse("2014-12-29 20:16:32 -0400")
=> 2014-12-30 11:16:32 +1100
~~~

But in Ruby 2.2, this is not the case:

~~~ruby
>> require 'time'
>> ENV['TZ'] = 'Australia/Melbourne'
>> Time.parse("2014-12-29 20:16:32 -0400")
=> 2014-12-29 20:16:32 -0400 # !!
>> Time.parse("2014-12-29 20:16:32 -0400").localtime
=> 2014-12-30 11:16:32 +1100
~~~

This seems to be a regression, as this is a change in default behaviour without a `MAJOR` version bump, violating semver.



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