| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
The concept of a blank date or time doesn't make sense so we can short
circuit the calls for `blank?` on these classes to gain small speed boost.
Fixes #21657
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
|
|
|
| |
ActiveSupport::TimeWithZone references `ActiveSupport::Duration` but
does not require it, which can result in a `LoadError` when required
directly without requiring a component less granular like
`active_support/time`, where the autoload for `ActiveSupport::Duration`
is set up.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stems from [Google group discussion](https://groups.google.com/forum/#!topic/rubyonrails-core/jSPbP-TNLb0).
Currently `AS::TimeWithZone` has two methods to add an interval to a time:
`+(other)` and `since(other)` ([docs](http://edgeapi.rubyonrails.org/classes/ActiveSupport/TimeWithZone.html)).
The two methods are "pretty much" equivalent in every case:
1. When adding any interval to an `AS::TimeWithZone` representing a `Time`:
```ruby
t = Time.now.in_time_zone #=> Thu, 04 Dec 2014 18:56:28 EST -05:00
t + 1 == t.since(1) #=> true
t + 1.day == t.since(1.day) #=> true
t + 1.month == t.since(1.month) #=> true
```
2. When adding any interval to an `AS::TimeWithZone` representing a `Date`:
```ruby
d = Date.today.in_time_zone #=> Thu, 04 Dec 2014 00:00:00 EST -05:00
d + 1 == d.since(1) #=> true
d + 1.day == d.since(1.day) #=> true
d + 1.month == d.since(1.month) #=> true
```
3. When adding any interval to an `AS::TimeWithZone` representing a `DateTime`:
```ruby
dt = DateTime.now.in_time_zone #=> Thu, 04 Dec 2014 18:57:28 EST -05:00
dt + 1 == dt.since(1) #=> true
dt + 1.day == dt.since(1.day) #=> true
dt + 1.month == dt.since(1.month) #=> false
```
As you can see, the only case in which they differ is when the interval added
to a `DateTime` is in a format like `1.month`.
However, this usage of "since" is explicitly discouraged by the
[documentation of `DateTime#since`](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/date_time/calculations.rb#L86L88):
> Returns a new DateTime representing the time a number of seconds since the instance time.
> Do not use this method in combination with x.months, use months_since instead!
And indeed, following this recommendation the correct result is returned:
```ruby
dt + 1.month == dt.months_since 1 #=> true
```
Therefore, my proposal is to remove the method definition of `TimeWithZone#since`
and instead replace it with a simple `alias_method :since, :+`.
The rationale is that the only case where they differ is a case that is
explicitly discouraged as "wrong".
In my opinion, having two methods named `since` and `+` and having to figure
out exactly what the difference is makes the codebase more confusing.
However, I understand this PR is "subjective", so if you feel like it's better
to ignore this, feel free to close the PR.
Thanks!
|
|\ |
|
| |
| |
| |
| |
| |
| | |
The example was taken from the commit message 676d6a6.
[ci skip]
|
|/
|
|
| |
[ci skip]
|
| |
|
|\
| |
| |
| | |
Fixed `ActiveSupport::TimeWithZone#-` so precision is not unnecessarily lost
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've noticed that `String(model.created_at)` is performing poorly in comparision
with other fields. The source of the problem is a way `Kernel#String` works: it first
tries to call `to_str` (which causes `NoMethodError` in `method_missing`) and then calls `to_s`.
Performance tests:
tz = Time.zone.now
Benchmark.ips do |x|
x.report { String(tz) }
end
Without this code:
Calculating -------------------------------------
572 i/100ms
-------------------------------------------------
10177.7 (±18.2%) i/s - 48620 in 5.000325s
With this code:
Calculating -------------------------------------
1518 i/100ms
-------------------------------------------------
138984.2 (±10.1%) i/s - 677028 in 4.974897s
|
|
|
| |
Current docs are wrong. Does not accept strftime inputs.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
According to 28ab79d7c579fa1d76ac868be02b38b02818428a
|
|
|
|
|
|
|
| |
Add `DateTime#usec` and `DateTime#nsec` so that `ActiveSupport::TimeWithZone`
keeps sub-second resolution when wrapping a `DateTime` value.
Fixes #10855
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
[ci skip]
|
| |
|
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
actionmailer/lib/action_mailer/base.rb
activesupport/lib/active_support/configurable.rb
activesupport/lib/active_support/core_ext/module/deprecation.rb
guides/source/action_controller_overview.md
guides/source/active_support_core_extensions.md
guides/source/ajax_on_rails.textile
guides/source/association_basics.textile
guides/source/upgrading_ruby_on_rails.md
While resolving conflicts, I have chosen to ignore changes done in
docrails at some places - these will be most likely 1.9 hash syntax
changes.
|
| | |
|
|/
|
|
| |
format strings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
|\
| |
| | |
wrap time ranges with timezones
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
|\ \
| |/
|/| |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|