| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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 9ce2d1b1a43fc4ef3db59849b7412d30583a4074, reversing
changes made to 53ede1aff2025d4391d0e05ba471fdaf3110a99c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
| |
Since 434df00 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, ActiveSupport::TimeWithZone#utc? simply runs a check to see
if the linked ActiveSupport::TimeZone's name is "UTC". This will only
return true for ActiveSupport::TimeZone["UTC"], but not for time zones
such as "Etc/UTC", "Etc/Universal", or other time zones that are aliases
for UTC. Interestingly enough, ActiveSupport::TimeWithZone#utc? is also
aliased as #gmt? but will return false for the "GMT" timezone (along
with other TZInfo aliases for GMT).
Instead of running a simple check on the TimeZone name, we can rely on
the underlying TZInfo::TimezonePeriod and TZInfo::TimezoneOffset which
keep a record of of the offset's abbreviated name. The possibilities
here for UTC time zones are `:UTC`, `:UCT`, and `:GMT`.
Signed-off-by: David <me@davidcel.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
```ruby
twz = DateTime.now.in_time_zone
twz.eql?(twz.dup) => false
```
Now:
```ruby
twz = DateTime.now.in_time_zone
twz.eql?(twz.dup) => true
```
Please notice that this fix the `TimeWithZone` comparison to itself,
not to `DateTime`. Based on #3725, `DateTime` should not be equal to
`TimeWithZone`.
|
|
|
|
|
| |
Same fix as 109e71d2bb6d2305a091fe7ea96d4f6e9c7cd52d but after
mocha got removed in 2f28e5b6417fd4e5d6060983b36262737558b613.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 2cc2fa3633edd96773023c6b09d07c7b9d9b841d.
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Rely on NameError#name instead of its error message
|
| |
| |
| |
| |
| |
| | |
Rubinius' error messages don't call `#inspect` on the concerned object
while the assertion is here to address a wrong inspection on MRI with
time zones so let's keep this test for now on Rubinius.
|
|/ |
|
| |
|
|
|
|
|
| |
It’s used at so many places that extracting it out into a helper file
is worth doing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working with objects with a nanosecond component, the `-` method may
unnecessarily cause loss of precision.
`ActiveSupport::TimeWithZone#-` should return the same result as if we were
using `Time#-`:
Time.now.end_of_day - Time.now.beginning_of_day #=> 86399.999999999
Before:
Time.zone.now.end_of_day.nsec #=> 999999999
Time.zone.now.end_of_day - Time.zone.now.beginning_of_day #=> 86400.0
After:
Time.zone.now.end_of_day - Time.zone.now.beginning_of_day
#=> 86399.999999999
|
|
|
|
|
|
|
| |
Extend the solution from the fix for #12163 to the general case where
`Time` methods are wrapped with a time zone.
Fixes #12596.
|
|
|
|
|
|
| |
Both Time#xmlschema and DateTime#xmlschema can accept nil values for the
fraction_digits parameter. This commit makes this so for TimeWithZone
values as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The subsecond fraction digits had been hardcoded to 3. This forced all
timestamps to include the subsecond digits with no way to customize the
value. While the subsecond format is part of the ISO8601 spec, it is not
adhered to by all parsers (notably mobile clients). This adds the
ability to customize the number of digits used, optionally setting them
to 0 in order to eliminate the subsecond fraction entirely:
ActiveSupport::JSON::Encoding.subsecond_fraction_digits = 0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
We need to call `in_time_zone` to test that it isn't modifying the receiver
but since the variable isn't used it raises a warning so add an assertion
to make Ruby think it's being used.
|
|
|
|
|
|
| |
Similar implementations of #in_time_zone exists for Date, Time and DateTime so
method is extracted into its own module. Also some logic is extracted into
private method.
|
|
|
|
|
|
|
|
| |
Rails 4.0.0 fails when trying to encode an ActiveSupport::TimeWithZone
that wraps a DateTime instance. This is fixed on master so add a test
to prevent regression.
(cherry picked from commit ad01b8da354268cebfae1519c28d19d75576ccb1)
|
| |
|
|
|
|
|
|
|
| |
Add `DateTime#usec` and `DateTime#nsec` so that `ActiveSupport::TimeWithZone`
keeps sub-second resolution when wrapping a `DateTime` value.
Fixes #10855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 2683de5da85135e8d9fe48593ff6167db9d64b18
Author: Aaron Patterson <aaron.patterson@gmail.com>
Date: Fri May 3 11:29:20 2013 -0700
cannot support infinite ranges right now
commit cebb6acef2c3957f975f6db4afd849e535126253
Author: Aaron Patterson <aaron.patterson@gmail.com>
Date: Fri May 3 11:26:12 2013 -0700
reverting infinity comparison
commit 385f7e6b4efd1bf9b89e8d607fcb13e5b03737ea
Author: Aaron Patterson <aaron.patterson@gmail.com>
Date: Fri May 3 11:23:28 2013 -0700
Revert "Added ability to compare date/time with infinity"
This reverts commit 38f28dca3aa16efd6cc3af6453f2e6b9e9655ec1.
Conflicts:
activesupport/CHANGELOG.md
activesupport/lib/active_support/core_ext/numeric/infinite_comparable.rb
activesupport/test/core_ext/date_ext_test.rb
activesupport/test/core_ext/date_time_ext_test.rb
activesupport/test/core_ext/numeric_ext_test.rb
activesupport/test/core_ext/time_ext_test.rb
activesupport/test/core_ext/time_with_zone_test.rb
commit 0d799a188dc12b18267fc8421675729917610047
Author: Aaron Patterson <aaron.patterson@gmail.com>
Date: Fri May 3 11:18:53 2013 -0700
Revert "Refactor infinite comparable definition a bit"
This reverts commit dd3360e05e4909f2f0c74a624cccc2def688f828.
commit 42dec90e49745bbfae546f0560b8783f6b48b074
Author: Aaron Patterson <aaron.patterson@gmail.com>
Date: Fri May 3 11:18:47 2013 -0700
Revert "Require 'active_support/core_ext/module/aliasing' in the infinite_comparable module"
This reverts commit 7003e71c13c53ec3d34250560fbf80b8381df693.
|
|
|
|
|
|
|
|
|
| |
Closes #9772.
`TimeWithZone` delegates everything to the wrapped `Time` object
using `method_missing`. The result is that `NoMethodError` error
will be raised in the context of `Time` which leads to a misleading
debug output.
|
| |
|
| |
|
|
|
|
| |
since it's allowed by the spec and is very useful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Date, DateTime, Time and TimeWithZone can now be compared to infinity,
so it's now possible to create ranges with one infinite bound and
date/time object as another bound.
Ex.: @range = Range.new(Date.today, Float::INFINITY)
Also it's possible to check inclusion of date/time in range with
conversion.
Ex.: @range.include?(Time.now + 1.year) # => true
@range.include?(DateTime.now + 1.year) # => true
Ability to create date/time ranges with infinite bound is required
for handling postgresql range types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
when we pass fractional usec to Time methods we should use Rational
instead of Float because of accuracy problem
Time.local(2011,6,12,23,59,59,999999.999).nsec
# => 999999998
Time.local(2011,6,12,23,59,59,Rational(999999999, 1000)).nsec
# => 999999999
|
|\
| |
| | |
Respond to missing
|
| | |
|
|\ \
| | |
| | | |
Beginning and end of hour support for Time and DateTime
|
| |/ |
|
|/
|
|
| |
test for future_with_time_current_as_time_with_zone; fix beginning_of_month test.
|
| |
|
|
|
|
|
|
| |
There are a bunch of other implicit branches that adds
1.8.x specific code that still needs to be removed. Pull
requests for those cases are welcome.
|