| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
See: https://github.com/ruby/ruby/commit/44a2576f798b07139adde2d279e48fdbe71a0148
https://github.com/ruby/ruby/commit/9df88e9cae57aa421230f14500e88f33f127414f
|
|
|
|
| |
because Struct.new returns a Class, we just can give it a name and use it directly without inheriting from it
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
ensure `#compact` of HWIDA to return HWIDA
|
| |
| |
| |
| |
| |
| |
| |
| | |
`Hash#compact` of Ruby native returns new hash.
Therefore, in order to return HWIDA as in the past version, need to
define own `#compact` to HWIDA.
Related: #26868
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ruby 2.4.0 has trouble duplicating certain symbols created from
strings via `to_sym`.
It didn't happen with `'symbol'.to_sym.dup` for some reason, but
works fine with the longer string sample.
Once a newer Ruby version with a fix is released we'll get have
a failing test case we can fix.
Ref: #27532
|
|
|
|
|
|
| |
Some methods were added to public API in
5b14129d8d4ad302b4e11df6bd5c7891b75f393c and they should be not part of
the public API.
|
| |
|
|
|
|
| |
minitest 6."
|
| |
|
| |
|
| |
|
|
|
|
| |
See [this test](https://gist.github.com/utilum/78918f1b64f8b61ee732cb266db7c43a).
|
| |
|
|
|
|
|
|
|
| |
`NilClass`, `FalseClass`, `TrueClass`, `Symbol` and `Numeric` can dup
with Ruby 2.4+.
Ref: https://bugs.ruby-lang.org/issues/12979
|
| |
|
|
|
|
| |
https://bugs.ruby-lang.org/issues/12979
|
|
|
|
|
|
|
|
| |
This behavior changed in Ruby starting with 2.3.0, as a result of
https://bugs.ruby-lang.org/issues/11360. This results in a change in
behavior of these methods which is likely undesirable.
Fixes #27238
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 }`.
|
|\
| |
| | |
Remove Active Support deprecations
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit bad3a120f1690f393d8f6204b3ceee60f0ce707b, reversing
changes made to 2384317465ccb1dfca456a2b7798714b99f32711.
Reason: Adding a new option in the API for something that can be done
with a `#presence` check could do.
|
|/
|
|
| |
value. See also http://patshaughnessy.net/2014/1/9/how-big-is-a-bignum for smallest bignum value
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`copy_time_to` is a helper function for date and time calculations.
It's being used by `prev_week`, `next_week` and `prev_weekday` to keep
the time fraction when jumping around between days.
Previously the nanoseconds part was lost during the operation. This
lead to problems in practice if you were using the `end_of_day`
calculation. Resulting in the time fraction of `end_of_day` not being
the same as next week's `end_of_day`.
With this fix `copy_time_to` doesn't forget the `nsec` digits.
|
|
|
|
| |
https://bugs.ruby-lang.org/issues/12739
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|
| |
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|\
| |
| |
| | |
Fix `thread_mattr_accessor` share variable superclass with subclass
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current implementation of `thread_mattr_accessor` set variable
sharing superclass with subclass. So the method doesn't work as documented.
Precondition
class Account
thread_mattr_accessor :user
end
class Customer < Account
end
Account.user = "DHH"
Account.user #=> "DHH"
Customer.user = "Rafael"
Customer.user # => "Rafael"
Documented behavior
Account.user # => "DHH"
Actual behavior
Account.user # => "Rafael"
Current implementation set variable statically likes `Thread[:attr_Account_user]`,
and customer also use it.
Make variable name dynamic to use own thread-local variable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| | |
|
| | |
|
| | |
|