So strings can be humanized without being capitalized:
'employee_salary'.humanize # => "Employee salary"
'employee_salary'.humanize(capitalize: false) # => "employee salary"
TL;DR The primary driver is to remove autoload surprise.
This is related to #12106. (The root cause for that ticket is that
json/add defines Regexp#to_json among others, but here I'll reproduce
the problem without json/add.)
Before:
>> require 'active_support/core_ext/to_json'
=> true
>> //.as_json
NoMethodError: undefined method `as_json' for //:Regexp
from (irb):3
from /Users/godfrey/.rvm/rubies/ruby-2.0.0-p195/bin/irb:16:in `<main>'
>> //.to_json
=> "\"(?-mix:)\""
>> //.as_json
=> "(?-mix:)"
After:
>> require 'active_support/core_ext/to_json'
=> true
>> //.as_json
=> "(?-mix:)"
This is because ActiveSupport::JSON is autoloaded the first time
Object#to_json is called, which causes additional core extentions
(previously defined in active_support/json/encoding.rb) to be loaded.
When someone require 'active_support/core_ext', the expectation is
that it would add certain methods to the core classes NOW. The
previous behaviour causes additional methods to be loaded the first
time you call `to_json`, which could cause nasty surprises and other
unplesant side-effects.
This change moves all core extensions in to core_ext/json. AS::JSON is
still autoloaded on first #to_json call, but since it nolonger
include the core extensions, it should address the aforementioned bug.
*Requiring core_ext/object/to_json now causes a deprecation warnning*
* eliminates need for temp Hash
Also added a couple of examples to DurationTest to specify:
* duration can be defined with units out of order e.g.
1.month + 1.year + 1.second + 1.day
* equality with a Fixnum works regardless of which operand is on which
side of the operator
We need to call `in_time_zone` to test that it isn't modifying the receiver
but since the variable isn't used it raises a warning so add an assertion
to make Ruby think it's being used.
Similar implementations of #in_time_zone exists for Date, Time and DateTime so
method is extracted into its own module. Also some logic is extracted into
private method.
Use a lambda to ensure that the generated string respects the offset of
the time value. Also add DateTime#to_s(:iso8601) and Date#to_s(:iso8601)
for completeness.
This fixes situations where nested NoMethodError exceptions are masked
by delegations. This would cause confusion especially where there was a
problem in the Rails booting process because of a delegation in the
routes reloading code.
Fixes#10559
Rails 4.0.0 fails when trying to encode an ActiveSupport::TimeWithZone
that wraps a DateTime instance. This is fixed on master so add a test
to prevent regression.
(cherry picked from commit ad01b8da354268cebfae1519c28d19d75576ccb1)
The standard Ruby behavior for Time.at is to return the same type of
time when passing an instance of Time as a single argument. Since the
an ActiveSupport::TimeWithZone instance may be a different timezone than
the system timezone and DateTime just understands offsets the best we
can do is to return an instance of Time with the correct offset.
Fixes#11350.
When Time.at_with_coercion (wraps Time.at) is called with a single
argument that "acts_like?(:time)" it is coerced to integer thus losing
it's microsecond percision.
This commits changes this to use `#to_f` to prevent the problem
Hash#select! returns nil if the hash didn't change and thus behaves differently
from select, so it's return value can't be used as result for the latter.
Add `DateTime#usec` and `DateTime#nsec` so that `ActiveSupport::TimeWithZone`
keeps sub-second resolution when wrapping a `DateTime` value.
Fixes#10855
Time.at allows passing a single Time argument which is then converted
to an integer. The conversion code since 1.9.3r429 explicitly checks
for an instance of Time so we need to override it to allow DateTime
and ActiveSupport::TimeWithZone values.