Ruby 2.4 #to_time incompatibility

[jeremy]

Ruby 2.4 changes Time#to_time and DateTime#to_time to preserve timezone. This is a good thing, but it breaks Active Support's scheme to harmonize #to_time behavior.

Example build failures:

• https://github.com/rails/rails/blob/master/activesupport/test/core_ext/date_time_ext_test.rb#L55
• https://github.com/rails/rails/blob/master/activesupport/test/core_ext/time_with_zone_test.rb#L423
• https://travis-ci.org/rails/rails/jobs/124101215#L533-L542

Ruby changes:

• DateTime: https://bugs.ruby-lang.org/issues/12189
• Time: https://bugs.ruby-lang.org/issues/12271

We'll need to update our #to_time to feature-detect the new versions and behave consistently on Ruby 2.3.0 and 2.4.0.

[jeremy]

/cc @pixeltrix @sonots @hsbt

[yui-knk]

On Ruby 2.3.0, #to_time uses system timezone of #to_time is called (this precedes timezone of a receiver object).
On Ruby 2.4.0, will use timezone of a receiver object.

behave consistently on Ruby 2.3.0 and 2.4.0

means "using system timezone of #to_time is called" on both Ruby 2.3.0 and 2.4.0 ?

[jeremy]

@yui-knk Yes, use local (system tz). We had to compromise when our only options were local tz or utc. I wish we could have preserved tz of the receiver all along!

This is an unfortunate situation, then, since changing #to_time behavior will require a major Rails change (5.0.0) and will need a configuration flag to enable. Plus we'll need to emulate Ruby 2.4 #to_time for Date/Time/DateTime on Ruby 2.2 and 2.3, which I'm not sure is possible due to internal API usage.

[jeremy]

(Ref ruby/ruby#1295)

[pixeltrix]

Ugh, will have a look at this today

[jeremy]

🤘
On Sat, Apr 23, 2016 at 07:12 Andrew White notifications@github.com wrote:

Closed #24617 #24617 via c9c5788
c9c5788
.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#24617 (comment)