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]

This is just to remove astonishment from getting `3600 seconds` from typing `1.hour`.

Regression: adding minutes/hours to a time would change its time zone

This reverts commit 1bf9fe75.

This can be an issue when TZInfo::TimeZone#current_period is refreshed
due to timezone period transition, but it's not reflected in
ActiveSupport::TimeZone object.

For example, on Sun, 26 Oct 2014 22:00 UTC, Moscow changed its TZ from
MSK +04:00 to MSK +03:00 (-1 hour). If ActiveSupport::TimeZone['Moscow']
happens to be initialized just before the timezone transition, it will
cache its stale utc_offset even after the timezone transition.

This commit removes cache and fixes this issue.
Signed-off-by: NJeremy Daer <jeremydaer@gmail.com>

[ci skip]

Previously these methods could return either a DateTime or a Time
depending on how the ActiveSupport::TimeWithZone instance had
been constructed. Changing to always return an instance of Time
eliminates a possible stack level too deep error in to_time where
it was wrapping a DateTime instance.

As a consequence of this the internal time value is now always an
instance of Time in the UTC timezone, whether that's as the UTC
time directly or a representation of the local time in the timezone.

There should be no consequences of this internal change and if
there are it's a bug due to leaky abstractions.

Mirrors the Time#subsec method by returning the fraction
of the second as a Rational.