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.
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 2cc2fa3.
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.
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
This fixes situations where nested NoMethodError exceptions are masked by delegations. This would cause confusion especially where there was a problem in the Rails booting process because of a delegation in the routes reloading code. Fixes #10559
The standard Ruby behavior for Time.at is to return the same type of time when passing an instance of Time as a single argument. Since the an ActiveSupport::TimeWithZone instance may be a different timezone than the system timezone and DateTime just understands offsets the best we can do is to return an instance of Time with the correct offset. Fixes #11350.
Add `DateTime#usec` and `DateTime#nsec` so that `ActiveSupport::TimeWithZone` keeps sub-second resolution when wrapping a `DateTime` value. Fixes #10855
Time.at allows passing a single Time argument which is then converted to an integer. The conversion code since 1.9.3r429 explicitly checks for an instance of Time so we need to override it to allow DateTime and ActiveSupport::TimeWithZone values.
This commit standardises the return value of `to_time` to an instance of `Time` in the local system timezone, matching the Ruby core and standard library behavior. The default form for `String#to_time` has been changed from :utc to :local but research seems to suggest the latter is the more common form. Also fix an edge condition with `String#to_time` where the string has a timezone offset in it and the mode is :local. e.g: # Before: >> "2000-01-01 00:00:00 -0500".to_time(:local) => 2000-01-01 05:00:00 -0500 # After: >> "2000-01-01 00:00:00 -0500".to_time(:local) => 2000-01-01 00:00:00 -0500 Closes #2453
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.
The to_time_in_current_zone method doesn't match the naming of the methods for converting to ActiveSupport::TimeWithZone on Time and DateTime. Since DateTime inherits from Date that has led to confusion with some users using the to_time_in_current_zone method with DateTime instances and having the time part dropped and the UTC offset lost. This commit fixes this by deprecating the old method and adding a new in_time_zone method which matches the naming for DateTime and Time. This should prevent accidently dropping times and UTC offsets when converting DateTime instances to ActiveSupport::TimeWithZone.
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.