| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
| |
Skipping over 2.4.0 to sidestep the `"symbol_from_string".to_sym.dup` bug.
References #32028
|
|
|
|
|
| |
Without this require, an error occurs when executing only `duration_test.rb`.
Ref: https://travis-ci.org/rails/rails/jobs/338817558#L2205-L2210
|
|\
| |
| | |
Fix yaml deserialization of ActiveSupport::Duration
|
| |
| |
| |
| |
| |
| | |
This ensures the duration's @parts hash has a default value, to avoid this regression introduced in 5.1:
YAML.load(YAML.dump(10.minutes)) + 1 # => NoMethodError: undefined method `+' for nil:NilClass
|
|\ \
| | |
| | | |
Duration created with no parts will have a default seconds part eqaul to 0
|
| | | |
|
|/ /
| |
| |
| | |
Follow up of #31390.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rails 5.1 introduce an `ActiveSupport::Duration::Scalar` class as
a wrapper around a numeric value as a way of ensuring a duration
was the outcome of an expression. However the implementation was
missing support for modulo operations. This commit adds support
for those operations and should result in a duration being
returned from expressions involving them.
Fixes #29603 and #29743.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
PR #29163 introduced a change in behavior when a duration was
the denominator in a calculation - this was incorrect as dividing
by a duration should always return a `Numeric`. The behavior of
previous versions of Rails has been restored.
Fixes #29592.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously calculations where the scalar is first would be converted
to a duration of seconds but this causes issues with dates being
converted to times, e.g:
Time.zone = "Beijing" # => Asia/Shanghai
date = Date.civil(2017, 5, 20) # => Mon, 20 May 2017
2 * 1.day # => 172800 seconds
date + 2 * 1.day # => Mon, 22 May 2017 00:00:00 CST +08:00
Now the `ActiveSupport::Duration::Scalar` calculation methods will try
to maintain the part structure of the duration where possible, e.g:
Time.zone = "Beijing" # => Asia/Shanghai
date = Date.civil(2017, 5, 20) # => Mon, 20 May 2017
2 * 1.day # => 2 days
date + 2 * 1.day # => Mon, 22 May 2017
Fixes #29160, #28970.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #28204 we deprecated implicit conversion of durations to a
numeric which represented the number of seconds in the duration
because of unwanted side effects with calculations on durations
and dates. This unfortunately had the side effect of forcing a
explicit cast when configuring third-party libraries like
expiration in Redis, e.g:
redis.expire("foo", 5.minutes)
To work around this we've removed the deprecation and added a
private class that wraps the numeric and can perform calculation
involving durations and ensure that they remain a duration
irrespective of the order of operations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `ActiveSupport::Duration` implicitly converts to a seconds
value when used in a calculation except for the explicit examples of
addition and subtraction where the duration is the receiver, e.g:
>> 2 * 1.day
=> 172800
This results in lots of confusion especially when using durations
with dates because adding/subtracting a value from a date treats
integers as a day and not a second, e.g:
>> Date.today
=> Wed, 01 Mar 2017
>> Date.today + 2 * 1.day
=> Mon, 10 Apr 2490
To fix this we're implementing `coerce` so that we can provide a
deprecation warning with the intent of removing the implicit coercion
in Rails 5.2, e.g:
>> 2 * 1.day
DEPRECATION WARNING: Implicit coercion of ActiveSupport::Duration
to a Numeric is deprecated and will raise a TypeError in Rails 5.2.
=> 172800
In Rails 5.2 it will raise `TypeError`, e.g:
>> 2 * 1.day
TypeError: ActiveSupport::Duration can't be coerced into Integer
This is the same behavior as with other types in Ruby, e.g:
>> 2 * "foo"
TypeError: String can't be coerced into Integer
>> "foo" * 2
=> "foofoo"
As part of this deprecation add `*` and `/` methods to `AS::Duration`
so that calculations that keep the duration as the receiver work
correctly whether the final receiver is a `Date` or `Time`, e.g:
>> Date.today
=> Wed, 01 Mar 2017
>> Date.today + 1.day * 2
=> Fri, 03 Mar 2017
Fixes #27457.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's common in test cases at my job to have code like this:
let(:today) { customer_start_date + 2.weeks }
let(:earlier_date) { today - 5.days }
With this change, we can instead write
let(:today) { 2.weeks.after(customer_start_date) }
let(:earlier_date) { 5.days.before(today) }
Closes #27721
|
|
|
|
|
|
|
| |
Since 1.month no longer equals 30.days add some tests to ensure that
addition maintains the same day in the month or is the last day in
the month if the month has less days than the current day. Also add
a test for the behaviour of 12.months == 1.year.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
durations from code
ActiveSupport::Duration.parse('P3Y') == 3.years # It should be true
Duration parsing made independent from any moment of time:
Fixed length in seconds is assigned to each duration part during parsing.
Changed duration of months and years in seconds to more accurate and logical:
1. The value of 365.2425 days in Gregorian year is more accurate
as it accounts for every 400th non-leap year.
2. Month's length is bound to year's duration, which makes
sensible comparisons like `12.months == 1.year` to be `true`
and nonsensical ones like `30.days == 1.month` to be `false`.
Calculations on times and dates with durations shouldn't be affected as
duration's numeric value isn't used in calculations, only parts are used.
Methods on `Numeric` like `2.days` now use these predefined durations
to avoid duplicating of duration constants through the codebase and
eliminate creation of intermediate durations.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, `3.months - 3.months` would result in a duration
that has the "parts" of `[[:months, 3], [:months, -3]]`. This would mean
that it was subtly different than `2.months - 2.months`. When applied to
a time, the date might actually change if the resulting day doesn't
exist however many months in the future, even though in both cases we
just wanted to add `0`, which should always be an identity operation.
With this change, we now store the parts as a hash, so `3.months -
3.months` is simply stored as `{ months: 0 }`.
|
|
|
|
|
|
|
|
| |
2.3: sprintf('%0.1f', 5.55) #=> "5.5"
2.4: sprintf('%0.1f', 5.55) #=> "5.6"
see: https://github.com/ruby/ruby/commit/6ed8c79ddb11ccfb580bb0a22b22cc1362250255 and
https://github.com/ruby/ruby/commit/295f60b94d5ff6551fab7c55e18d1ffa6a4cf7e3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `ActiveSupport::Duration.parse` used `Time.current` and
`Time#advance` to calculate the number of seconds in the duration
from an arbitrary collection of parts. However as `advance` tries to
be consistent across DST boundaries this meant that either the
duration was shorter or longer depending on the time of year.
This was fixed by using an absolute reference point in UTC which
isn't subject to DST transitions. An arbitrary date of Jan 1st, 2000
was chosen for no other reason that it seemed appropriate.
Additionally, duration parsing should now be marginally faster as we
are no longer creating instances of `ActiveSupport::TimeWithZone`
every time we parse a duration string.
Fixes #26941.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation serializes zero-length durations incorrectly (it serializes as `"-P"`), and cannot un-serialize itself:
```
[1] pry(main)> ActiveSupport::Duration.parse(0.minutes.iso8601)
ActiveSupport::Duration::ISO8601Parser::ParsingError: Invalid ISO 8601 duration: "-P" is empty duration
from /Users/rando/.gem/ruby/2.3.1/gems/activesupport-5.0.0/lib/active_support/duration/iso8601_parser.rb:96:in `raise_parsing_error'
```
Postgres empty intervals are serialized as `"PT0S"`, which is also parseable by the Duration deserializer, so I've modified the `ISO8601Serializer` to do the same.
Additionally, the `#normalize` function returned a negative sign if `parts` was blank (all zero). Even though this fix does not rely on the sign, I've gone ahead and corrected that, too, in case a future refactoring of `#serialize` uses it.
|
|
|
|
|
|
|
|
| |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
|
|
|
| |
This is just to remove astonishment from getting `3600 seconds` from typing `1.hour`.
|
|
|
|
|
|
| |
Regression: adding minutes/hours to a time would change its time zone
This reverts commit 1bf9fe75a6473cb7501cae544cab772713e68cef.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```ruby
ActiveSupport::Duration.parse('P3Y6M4DT12H30M5S')
(3.years + 3.days).iso8601
```
Inspired by Arnau Siches' [ISO8601 gem](https://github.com/arnau/ISO8601/)
and rewritten by Andrey Novikov with suggestions from Andrew White. Test
data from the ISO8601 gem redistributed under MIT license.
(Will be used to support the PostgreSQL interval data type.)
|
|
|
|
| |
This is just to remove astonishment from getting `3600 seconds` from typing `1.hour`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi there,
i have an app without english as available locale. So i got an error when we try to inspect something like 1.day. This is done automatically when we use the dalli cache.
I would like to change the :en to ::I18n.default_locale to be sure that this is always constant and is an available locale.
Tests are all green with this change.
Calculating -------------------------------------
:locale => :en 2.024k i/100ms
:locale => ::I18n.default_locale 2.236k i/100ms
-------------------------------------------------
:locale => :en 25.758k (±26.3%) i/s - 117.392k
:locale => ::I18n.default_locale 26.311k (±18.1%) i/s - 127.452k
|
|\
| |
| | |
Delegate comparison operator to value
|
| | |
|
|/
|
|
|
| |
- Reference : https://github.com/rails/rails/pull/17493#issuecomment-61739359
- Duration stopped inheriting from ProxyObject in https://github.com/rails/rails/pull/16574
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The assertions in AS::Duration don't actually assert.
* The assertion in Railtie will pass even when `eager_load_namespaces`
doesn't include `AppTemplate::Application` if `Rails.application` is
truthy.
For more details, see here:
* https://github.com/rails/rails/pull/16998
* https://github.com/rails/rails/pull/17000
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Added method `#eql?` to `ActiveSupport::Duration`, in addition to `#==`.
Conflicts:
activesupport/CHANGELOG.md
activesupport/lib/active_support/duration.rb
activesupport/test/core_ext/duration_test.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, the following returns `false`, contrary to expectation:
1.minute.eql?(1.minute)
Adding method `#eql?` will make this behave like expected. Method `#eql?` is
just a bit stricter than `#==`, as it checks whether the argument is also a
uration. Their parts may be different though.
1.minute.eql?(60.seconds) # => true
1.minute.eql?(60) # => false
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since Rubinius is relying on #instance_of? for its definition of #eql?
(http://git.io/MtmbbA) but ActiveSupport::Duration should behave like
is_a? it returns true with `Fixnum`.
Thus, for the moment, the last assertion is failing so we have to skip
this test.
|
| |
| |
| |
| |
| |
| |
| | |
For the sake of backward-compatibility, we need to make #instance_of?
return true for Fixnum. On the other hand, the method should still
give true for ActiveSupport::Duration itself which was not the case
before.
|