By this way Integer, Rational, Float, Fixnum, Bignum classes have the same behaviour

Previously when converting AS::TimeWithZone to YAML it would be output
as a UTC timestamp. Whilst this preserves the time information accurately
it loses the timezone information. This commit changes that so that it is
saved along with the time information. It also provides nicer encoding of
AS::TimeZone instances themselves which previously embedded all of the
data from the TZInfo records.

Fixes #9183.

This makes it easier to parse user-inputted times as from a given time zone.

At present, if you skip a callback that hasn't been defined,
activesupport callbacks silently does nothing. However, it's easy to
mistype the name of a callback and mistakenly think that it's being
skipped, when it is not.

This problem even exists in the current test suite.
CallbacksTest::SkipCallbacksTest#test_skip_person attempts to skip
callbacks that were never set up.

This PR changes `skip_callback` to raise an `ArgumentError` if the
specified callback cannot be found.

This reverts commit 9420de59.

Reason: Turns out we want to keep this method.

We are promoting too much a feature that will not be widler used.
So for now lets keep just the ArrayInquirer constructor.

Wrapping an array in an `ArrayInquirer` gives a friendlier way to check its
string-like contents. For example, `request.variant` returns an `ArrayInquirer`
object. To check a request's variants, you can call:

    request.variant.phone?
    request.variant.any?(:phone, :tablet)

...instead of:

    request.variant.include?(:phone)
    request.variant.any? { |v| v.in?([:phone, :tablet]) }

`Array#inquiry` is a shortcut for wrapping the receiving array in an
`ArrayInquirer`:

    pets = [:cat, :dog]
    pets.cat?    # => true
    pets.ferret? # => false
    pets.any?(:cat, :ferret} # => true

…as discussed #19413

Reverting this as it's not the implementation that we would like it to be.
This is being used inside of ActiveSUpport::TimeZone[] and it's unaware
of the context in which to find the timezone period so the timezone found
changes depending on whether DST is in effect for the current period.
This means that `'2001-01-01'.in_time_zone(-9)` changes from winter/summer
even though it's the same date that we're trying to convert.

Since finding timezones by numeric offsets is a bit hit and miss we should
introduce a new API for finding them which supplies the date context in
which we want to search and we should probably also deprecate the finding
of timezones via the [] method, though this needs further discussion.

This reverts commit 2cc2fa36.

This entry now lives in the Action View's changelog ; refs 8a3bd089.

Closes #19227.

When given a specific offset, use the first result found where the
total current offset (including any periodic deviations such as DST)
from UTC is equal.

Fixes #19070.

`coder.represent_scalar` means something along the lines of "Here is a quoted
string, you can just add it to the output", which is not the case here. It only
works for simple strings that can appear unquoted in YAML, but causes problems
for e.g. primitive-like strings ("1", "true").

`coder.represent_object` on the other hand, means that "This is the Ruby-object
representation for this thing suitable for use in YAML dumping", which is what
we want here.

Before:

   YAML.load ActiveSupport::SafeBuffer.new("Hello").to_yaml  # => "Hello"
   YAML.load ActiveSupport::SafeBuffer.new("true").to_yaml   # => true
   YAML.load ActiveSupport::SafeBuffer.new("false").to_yaml  # => false
   YAML.load ActiveSupport::SafeBuffer.new("1").to_yaml      # => 1
   YAML.load ActiveSupport::SafeBuffer.new("1.1").to_yaml    # => 1.1

 After:

   YAML.load ActiveSupport::SafeBuffer.new("Hello").to_yaml  # => "Hello"
   YAML.load ActiveSupport::SafeBuffer.new("true").to_yaml   # => "true"
   YAML.load ActiveSupport::SafeBuffer.new("false").to_yaml  # => "false"
   YAML.load ActiveSupport::SafeBuffer.new("1").to_yaml      # => "1"
   YAML.load ActiveSupport::SafeBuffer.new("1.1").to_yaml    # => "1.1"

If we ever want Ruby to behave more like PHP or JavaScript though, this is an
excellent trick to use ;)

It's a thin layer to provide easy access to sample files throughout
test-cases. This adds the directory `test/fixtures/files` to newly
generated applications.

Also sync Russian Federation time zones with `zone.tab` file from tzdata version 2014j.

Add #prev_day and #next_day as counterparts to #yesterday and #tomorrow for Date, Time, and DateTime

`#on_weekend?` returns true if the receiving date/time falls on a Saturday or
Sunday.

`#next_weekday` returns a new date/time representing the next day that does
not fall on a Saturday or Sunday.

`#prev_weekday` returns a new date/time representing the previous day that
does not fall on a Saturday or Sunday.

`silence_stderr`, `silence_stream`, `capture` and `quietly`.

This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:

* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.

For this purpose, this commit introduces a Rails configuration option:

```ruby
config.active_support.halt_callback_chains_on_return_false
```

For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:

```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```

For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.

Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.

Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.

A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931

After this commit, returning `false` in a callback will display a deprecation
warning to make developers aware of the fact that they need to explicitly
`throw(:abort)` if their intention is to halt a callback chain.

This commit also patches two internal uses of AS::Callbacks (inside
ActiveRecord and ActionDispatch) which sometimes return `false` but whose
returned value is not meaningful for the purpose of execution.

In both cases, the returned value is set to `true`, which does not affect the
execution of the callbacks but prevents unrequested deprecation warnings from
showing up.

This commit changes arguments and default value of CallbackChain's :terminator
option.

After this commit, Chains of callbacks defined **without** an explicit
`:terminator` option will be halted as soon as a `before_` callback throws
`:abort`.

Chains of callbacks defined **with** a `:terminator` option will maintain their
existing behavior of halting as soon as a `before_` callback matches the
terminator's expectation. For instance, ActiveModel's callbacks will still
halt the chain when a `before_` callback returns `false`.