In the context of controller parameters, reverse_merge is commonly used
to provide defaults for user input. Having an alias to reverse_merge
called with_defaults feels more idiomatic for Rails.
An alternative to DeprecatedConstantProxy which works more transparently
with exceptions because it returns the object that the new constant
refers to rather than a proxy. This is then compatible with
`rescue OldException`.
some documentation
remove extra whitespace.
Added id in the middle test case and corrected some testcases.
Some Coding standard guidelines corrections as suggested by codeclimate.
Some more corrections suggested by codeclimate.
We are overriding it in `Time` and `ActiveSupport::TimeWithZone` so
there's no point in having it in the `DateAndTime::Compatibility`
module. Also add some docs for the `to_time` implementations.
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.
We (GitLab) hit into an issue that somewhere in the middleware
chain was throwing `:warden`, which was caught in the wrapping
middleware, but `LocalCache::Middleware` was not aware of it.
It should look like:
``` ruby
result = catch(:warden) do
@app.call(env)
end
```
Source: 090ed153db/lib/warden/manager.rb (L35-L37)
Using `ensure` could make sure that we would always do the cleanup,
and better yet, avoid `rescue Exception` which we all should know
that could cause some issues which could be very hard to debug.
Please check the discussion thread for more context:
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1402#note_25128108
In 4b685aa the regex in `titlelize` was updated to not match
apostrophes to better reflect the nature of the transformation.
Unfortunately this had the side effect of breaking capitalization
on the first word of a sub-string, e.g:
>> "This was 'fake news'".titleize
=> "This Was 'fake News'"
This is fixed by extending the look-behind to also check for a
word character on the other side of the apostrophe.
Fixes#28312.
The `Time.xmlschema` and consequently its alias `iso8601` accepts
timestamps without a offset in contravention of the RFC 3339
standard. This method enforces that constraint and raises an
`ArgumentError` if it doesn't.
Previously there was no way to get a RFC 3339 timestamp
into a specific timezone without either using `parse` or
chaining methods. The new method allows parsing directly
into the timezone, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("1999-12-31T14:00:00Z")
=> Fri, 31 Dec 1999 14:00:00 HST -10:00
This new method has stricter semantics than the current
`parse` method and will raise an `ArgumentError`
instead of returning nil, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("foobar")
ArgumentError: invalid date
>> Time.zone.parse("foobar")
=> nil
It will also raise an `ArgumentError` when either the
time or offset components are missing, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.rfc3339("1999-12-31")
ArgumentError: invalid date
>> Time.zone.rfc3339("1999-12-31T14:00:00")
ArgumentError: invalid date
Previously there was no way to get a ISO 8601 timestamp into a specific
timezone without either using `parse` or chaining methods. The new method
allows parsing directly into the timezone, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("1999-12-31T14:00:00Z")
=> Fri, 31 Dec 1999 14:00:00 HST -10:00
If the timestamp is a ISO 8601 date (YYYY-MM-DD) then the time is set
to midnight, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("1999-12-31")
=> Fri, 31 Dec 1999 00:00:00 HST -10:00
This new method has stricter semantics than the current `parse` method
and will raise an `ArgumentError` instead of returning nil, e.g:
>> Time.zone = "Hawaii"
=> "Hawaii"
>> Time.zone.iso8601("foobar")
ArgumentError: invalid date
>> Time.zone.parse("foobar")
=> nil
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.
Adding support for these options now allows us to update the
`DateTime#end_of` methods to match the equivalent `Time#end_of`
methods, e.g:
datetime = DateTime.now.end_of_day
datetime.nsec == 999999999 # => true
Fixes#21424.
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