ActiveSupport::Duration.parse('P3Y') == 3.years # It should be true

Duration parsing made independent from any moment of time:
Fixed length in seconds is assigned to each duration part during parsing.

Changed duration of months and years in seconds to more accurate and logical:

 1. The value of 365.2425 days in Gregorian year is more accurate
    as it accounts for every 400th non-leap year.

 2. Month's length is bound to year's duration, which makes
    sensible comparisons like `12.months == 1.year` to be `true`
    and nonsensical ones like `30.days == 1.month` to be `false`.

Calculations on times and dates with durations shouldn't be affected as
duration's numeric value isn't used in calculations, only parts are used.

Methods on `Numeric` like `2.days` now use these predefined durations
to avoid duplicating of duration constants through the codebase and
eliminate creation of intermediate durations.

See [this test](https://gist.github.com/utilum/78918f1b64f8b61ee732cb266db7c43a).

`NilClass`, `FalseClass`, `TrueClass`, `Symbol` and `Numeric` can dup
with Ruby 2.4+.

Ref: https://bugs.ruby-lang.org/issues/12979

This reverts commit bad3a120, reversing
changes made to 23843174.

Reason: Adding a new option in the API for something that can be done
with a `#presence` check could do.

Previously `ActiveSupport::Duration.parse` used `Time.current` and
`Time#advance` to calculate the number of seconds in the duration
from an arbitrary collection of parts. However as `advance` tries to
be consistent across DST boundaries this meant that either the
duration was shorter or longer depending on the time of year.

This was fixed by using an absolute reference point in UTC which
isn't subject to DST transitions. An arbitrary date of Jan 1st, 2000
was chosen for no other reason that it seemed appropriate.

Additionally, duration parsing should now be marginally faster as we
are no longer creating instances of `ActiveSupport::TimeWithZone`
every time we parse a duration string.

Fixes #26941.

- Ruby 2.4 has added Hash#compact and Hash#compact! so we can use it
  now.
- Reference: https://bugs.ruby-lang.org/issues/11818 and https://bugs.ruby-lang.org/issues/12863.

`copy_time_to` is a helper function for date and time calculations.
It's being used by `prev_week`, `next_week` and `prev_weekday` to keep
the time fraction when jumping around between days.

Previously the nanoseconds part was lost during the operation. This
lead to problems in practice if you were using the `end_of_day`
calculation. Resulting in the time fraction of `end_of_day` not being
the same as next week's `end_of_day`.

With this fix `copy_time_to` doesn't forget the `nsec` digits.

Turns out trying to cache on localtime with arguments is too hard
so we'll do it on DateAndTime::Compatibility#to_time instead.

This reverts commit 9ce2d1b1, reversing
changes made to 53ede1af.

Previously memoization in `localtime` wasn't taking the `utc_offset`
parameter into account when returning a cached value. It now caches the
computed value depending on the `utc_offset` parameter, e.g:

    Time.zone = "US/Eastern"

    t = Time.zone.local(2016,5,2,11)
    # => Mon, 02 May 2016 11:00:00 EDT -04:00

    t.localtime(-7200)
    # => 2016-05-02 13:00:00 -0200

    t.localtime(-3600)
    # => 2016-05-02 14:00:00 -0100

Previously calls to `in` were being sent to the non-DST aware
method `Time#since` via `method_missing`. It is now aliased to
the DST aware `ActiveSupport::TimeWithZone#+` which handles
transitions across DST boundaries, e.g:

    Time.zone = "US/Eastern"

    t = Time.zone.local(2016,11,6,1)
    # => Sun, 06 Nov 2016 01:00:00 EDT -05:00

    t.in(1.hour)
    # => Sun, 06 Nov 2016 01:00:00 EST -05:00

The current implementation of `thread_mattr_accessor` set variable
sharing superclass with subclass. So the method doesn't work as documented.

Precondition

    class Account
      thread_mattr_accessor :user
    end

    class Customer < Account
    end

    Account.user = "DHH"
    Account.user  #=> "DHH"
    Customer.user = "Rafael"
    Customer.user # => "Rafael"

Documented behavior

    Account.user  # => "DHH"

Actual behavior

    Account.user  # => "Rafael"

Current implementation set variable statically likes `Thread[:attr_Account_user]`,
and customer also use it.

Make variable name dynamic to use own thread-local variable.

Since 434df001 week durations are no longer converted to days. This means
we need to add :weeks to the parts that ActiveSupport::TimeWithZone will
consider being of variable duration to take account of DST transitions.

Fixes #26039.

See the rationale in the documentation included in this patch.

We are going to gradually introduce this predicate in the code base.

AEAD modes like `aes-256-gcm` provide both confidentiality and data authenticity, eliminating the need to use MessageVerifier to check if the encrypted data has been tampered with.
Signed-off-by: NJeremy Daer <jeremydaer@gmail.com>

Those are assertions that I really do miss from the standard
`ActiveSupport::TestCase`. Think of those as a more general version of
`assert_difference` and `assert_no_difference` (those can be implemented
by assert_changes, should this change be accepted).

Why do we need those? They are useful when you want to check a
side-effect of an operation. `assert_difference` do cover a really
common case, but we `assert_changes` gives us more control. Having a
global error flag? You can test it easily with `assert_changes`. In
fact, you can be really specific about the initial state and the
terminal one.

```ruby
error = Error.new(:bad)
assert_changes -> { Error.current }, from: nil, to: error do
  expected_bad_operation
end
```

`assert_changes` follows `assert_difference` and a string can be given
for evaluation as well.

```ruby
error = Error.new(:bad)
assert_changes 'Error.current', from: nil, to: error do
  expected_bad_operation
end
```

Check out the test cases if you wanna see more examples.

🍻

     as this can lead to confusing time stubbing.

     Instead of:

         travel_to 2.days.from_now do
           # 2 days from today
           travel_to 3.days.from_now do
             # 5 days from today
           end
         end

     preferred way to achieve above is:

         travel_to 2.days.from_now
         # 2 days from today

         travel_back
         travel_to 5.days.from_now
         # 5 days from today

Closes #24690
Fixes #24689

Move new CHANGELOG entry top [ci skip]

Remove parameter "options = nil" for #clear

We are currently using `%e` which adds a space before the result if the
digit is a single number. This leads to strings like `February  2, 2016`
which is undesireable. I've opted to replace with 0 padding instead of
removing the padding entirely, to preserve compatibility for those
relying on the fact that the width is constant, and to be consistent
with time formatting.

Fixes #25251.

Follows the same pattern as controllers and jobs. Exceptions raised in
delivery jobs (enqueued by `#deliver_later`) are also delegated to the
mailer's rescue_from handlers, so you can handle the DeserializationError
raised by delivery jobs:

```ruby
class MyMailer < ApplicationMailer
  rescue_from ActiveJob::DeserializationError do
    …
  end
```

ActiveSupport::Rescuable polish:
* Add the `rescue_with_handler` class method so exceptions may be
  handled at the class level without requiring an instance.
* Rationalize `exception.cause` handling. If no handler matches the
  exception, fall back to the handler that matches its cause.
* Handle exceptions raised elsewhere. Pass `object: …` to execute
  the `rescue_from` handler (e.g. a method call or a block to
  instance_exec) against a different object. Defaults to `self`.

Use the updated changelog from the first merge: 7254517f

References #22806, #24762.

[ci skip]