The thread_safe gem is being deprecated and all its code has been merged
into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly
the same as its predecessor except for fixes to two bugs discovered
during the merge.

`TimeZone` class is a part of `ActiveSupport` module. For Accessing `TimeZone` class, we need to call `ActiveSupport::TimeZone` instead of `TimeZone`.

individual `TimeZone` gives `NameError: uninitialized constant ‘TimeZone’ error

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.

Make strptime behave more like parse when components are missing and
share behavior between the two methods.

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

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.

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.

Conflicts:
	activesupport/lib/active_support/values/time_zone.rb

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

Since real timezone is loaded anyway in `#utc_offset`
which is called during `#create`

`try` allocates an array on every call, we should avoid calling it in
hotspots.  This reduced AttributeMethodsTest#test_setting_time_zone_aware_attribute_with_string
from 18k allocations to 14k

Just moved class methods up in file and moved `def self.` methods into `class << self`.

Namely, if the mday is omitted but any other upper components are, then instead
of supplying the mday from the current time, it defaults to 1.

Apparently we've been using a buggy feature for the past 6 years:

  https://bugs.ruby-lang.org/issues/9593

Currently if a time is changed during DST overlap in the autumn then the
method `period_for_local` will return the DST period. However if the
original time is not DST then this can be surprising and is not what is
generally wanted. This commit changes that behavior to maintain the current
period if it's in the list of periods returned by `periods_for_local`.

It is possible to alter the behavior of `period_for_local` by specifying a
second argument but since we may be change from another time that could be
either DST or not then this would give inconsistent results.

Fixes #12163.

Check `respond_to` before delegation due to: https://github.com/ruby/ruby/commit/d781caaf313b8649948c107bba277e5ad7307314

Lazy loading the tzinfo library doesn't really buy us anything because
the gem is installed as a dependency via the gemspec and if a developer
is using Active Support outside of Rails then they can cherry pick which
files to load anyway.

Fixes #13553

Ruby's Date class automatically gives us #yesterday, #today,
and #tomorrow. And ActiveSupport has a handy Time.zone.today
for getting a localized version. But there was no localized
version of #yesterday or #tomorrow. Until now.

The method doesn't really make much sense (find_tzinfo will succeed for any imput provided).

There's no point in having 2 almost identical (@lazy_zones_map and @zones_map) lazy initialized TZ instance caches.

Plain ruby Hashes are not thread safe.

Also update the documentation on the number of supported time zones.

The Time.time_with_datetime_fallback, Time.utc_time and Time.local_time
methods were added to handle the limitations of Ruby's native Time
implementation. Those limitations no longer apply so we are deprecating
them in 4.0 and they will be removed in 4.1.

Sometimes, on Mac OS X, programmers accidentally press Option+Space
rather than just Space and don’t see the difference. The problem is
that Option+Space writes a non-breaking space (0XA0) rather than a
normal space (0x20).

This commit removes all the non-breaking spaces inadvertently
introduced in the comments of the code.

When there are missing components in the Hash returned by
Date._parse only the date components should default to the
value of Time.zone.now, the time components should all
default to zero.

Chrome, Safari and Firefox serialize Date objects to strings such
as 'Mon May 28 2012 00:00:00 GMT-0700 (PDT)'. When these strings
are parsed the zone is interpreted as 'GMT-0700' which doesn't
exist in the TzInfo list of timezones.

By taking advantage of the improved date/time handling in 1.9.3
we can use `Date._parse` and the `:offset` value which is parsed
correctly.

Three tests were amended to make them pass:

1.  test_parse_with_old_date

    This needed changing to a different value because the original
    value was before EST was adopted so was being changed to a
    LMT (Local Mean Time) value after the change. It didn't before
    because `DateTime` just has offsets from UTC not timezones.

2.  test_parse_should_not_black_out_system_timezone_dst_jump

    Changed the implementation of this test as the stubs were
    dependent on internal implementation details of the test.
    Confirmed that the modified test still failed when the
    implementation of `parse` was restored to pre-#5571.

3.  test_parse_should_black_out_app_timezone_dst_jump

    Ditto.

Closes #5770.

Fixes #8095.

For reference, here is the discussion about the mapping being
incorrect:
http://rubyforge.org/pipermail/tzinfo-users/2012-November/000114.html

Time#at no longer raises an error for large values so we can remove
the rescue clause from ActiveSupport::TimeZone#to_f.

Correcting some confusion. Pago Pago is part of American Samoa, not Samoa. Further, Samoa and Tokelau jumped across the IDL from Dec 29 to Dec 31, 2011 switching from UTC-11 to UTC+13. American Samoa did not make the change and remains at UTC-11. Pacific/Fakaofo and Pacific/Apia are in TZInfo and documentation about the dateline change is in austalasia at IANA.