| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
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
|
| | |
|
| | |
|
|\ \
| |/
|/| |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Current implementation produce incorrect output when Time#usec returns
integer < 100000, because to_s doesn't add leading zeros.
|
|
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
|
|
|
| |
suggestion!
|
|
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
|
|
|
|
|
| |
use find_zone! as well as adding Railtie tests
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
|
|
| |
losing performance
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
| |
1.1 compatibility
|
| |
|
| |
|
|
|
|
|
|
| |
[#5344 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
| |
|