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.

The system timezone DST jump hour should not be blacked out by Time.zone.parse if current Time.zone does not do the jump at that time.

Fixes #5559.

Removed some useless docstrings and no-doc'ed some.

This wasn't a problem when require_tzinfo was only called from TimeZone#initialize, but now it's being called for every lookup to TimeZone.[] (via lazy_zones_map)

TimeZone lookup can occur when unmarshalling TimeWithZone objects, which is where I first saw the big slowdown (500ms for each Rails action that loaded from Rails.cache)

Fix tzinfo require (it broke test_raises_when_an_invalid_timezone_is_defined_in_the_config in railties)

[#4979 state:committed]

[#4942 state:committed]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>