| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
* Calculate first month of quarter instead of finding
* Calculate last month of quarter instead of finding
[Krzysztof Rybka + Rafael Mendonça França]
|
|\
| |
| |
| | |
Improve some DateAndTime calculations
|
| | |
|
|/
|
|
|
|
|
|
|
| |
DeepCover revealed that most of these `wday != 0 ? wday - 1 : 6`
were not entirely covered, i.e. the case of `wday == 0` was not tested:
https://deep-cover.github.io/rails-cover/activesupport/activesupport/lib/active_support/core_ext/date_and_time/calculations.rb.html#L351
There's actually no valid reason to consider Sunday a special case,
so this commit simply reajusts the values used for calculations.
|
| |
|
|
|
|
|
|
|
|
| |
This prevents duplication of code.
Prevent duplication of tests by moving them to `DateAndTimeBehavior`.
Related to #32185.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These methods were originally added in https://github.com/rails/rails/pull/26600
This includes a couple of refactors to make these methods behave more similarly to other Date/Time extensions added by Active Support:
1. Use `advance` instead of `since` and `ago` to time-travel — this is particularly important to keep the returned instance’s class matching `self`. Before this change:
today = Date.today # => Tue, 28 Nov 2017
today.class # => Date
today.next_occurring(:wednesday) # => Wed, 29 Nov 2017 00:00:00 UTC +00:00
today.next_occurring(:wednesday).class # => ActiveSupport::TimeWithZone
After this change, a Date (or Time, or DateTime) instance is properly returned (just like is shown in the new docs). This is generally how everything else in DateAndTime::Calculations works.
2. Move the tests from the DateTime tests to the DateAndTimeBehavior tests. The latter location is mixed in to the core_ext tests for _all_ of Date, Time, and DateTime to test the behavior across all of the classes. The previous location is for testing core_ext functionality added specifically just to DateTime.
3. Better docs!
|
| |
|
| |
|
| |
|
|
|
|
| |
This basically reverts 8da30ad6be34339124ba4cb4e36aea260dda12bc
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
state, and preserve_timezone flag.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #25880 we tried to cache localtime to fix the performance
regression but that proved to be difficult due to the fact that
localtime/getlocal can take a utc_offset argument. We tried
caching based on the argument but since the argument can be nil
sometimes that meant that if the TZ environment variable changed
then the cached value for nil became invalid. By moving the
caching to DateAndTime#compatibility we don't have to worry about
arguments since it doesn't take any.
There is a possible edge condition where preserve_timezone is set
to false and the system timezone changes then it could result in
a cached value being incorrect but the only way to fix this would
be to remove all caching and live with the performance issue.
|
|
|
|
|
| |
`Date.week_start` does not exist. `Date.beginning_of_week` seems to be correct.
Ref: #5339
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
| |
Useful for queries like:
Item.where(created_at: Date.current.all_day)
There was already a Time#all_day with the same behaviour, but for
queries like the above, Date is more convenient.
|
|\
| |
| |
| |
| | |
Conflicts:
guides/source/configuring.md
|
| | |
|
| |
| |
| |
| |
| | |
Follow up to
https://github.com/rails/rails/commit/c9c5788a527b70d7f983e2b4b47e3afd863d9f48
|
| |
| |
| |
| |
| |
| | |
https://github.com/rails/rails/commit/c9c5788a527b70d7f983e2b4b47e3afd863d9f48
[ci skip]
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Ruby 2.4 the `to_time` method for both `DateTime` and `Time` will
preserve the timezone of the receiver when converting to an instance
of `Time`. Since Rails 5.0 will support Ruby 2.2, 2.3 and later we
need to introduce a compatibility layer so that apps that upgrade do
not break. New apps will have a config initializer file that defaults
to match the new Ruby 2.4 behavior going forward.
For information about the changes to Ruby see:
https://bugs.ruby-lang.org/issues/12189
https://bugs.ruby-lang.org/issues/12271
Fixes #24617.
|
| |
|
| |
|
| |
|
|
|
| |
`DateTime.utc` is not a valid method. It gives `NoMethodError: undefined method `utc` for DateTime:Class`. As we know that we can calculate `utc` time from `Time` Class, but we can’t calculate `utc` time from `DateTime` Class.
|
| |
|
|
|
|
| |
core_ext/time"
|
|\
| |
| | |
Replace use of alias chains with prepend at core_ext/date and core_ext/time
|
| | |
|
|\ \
| |/
|/|
| | |
Amend `next_week` documentation [ci skip]
|
|/
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
| |
The build has failed when running the date/time ext tests in isolation
due to the missing extension, so better than adding a require is using
just Ruby in this case.
https://travis-ci.org/rails/rails/jobs/46107954#L1077
|
|
|
|
| |
Date, Time, and DateTime
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and DateTime
`#on_weekend?` returns true if the receiving date/time falls on a Saturday or
Sunday.
`#next_weekday` returns a new date/time representing the next day that does
not fall on a Saturday or Sunday.
`#prev_weekday` returns a new date/time representing the previous day that
does not fall on a Saturday or Sunday.
|
| |
|
| |
|
|
|
|
|
|
| |
Similar implementations of #in_time_zone exists for Date, Time and DateTime so
method is extracted into its own module. Also some logic is extracted into
private method.
|
| |
|
| |
|