aboutsummaryrefslogtreecommitdiffstats
path: root/activesupport/lib/active_support/time_with_zone.rb
Commit message (Collapse)AuthorAgeFilesLines
* Memoize coerced TimeWithZone value in TimeWithZone#localtime.Ryan De Villa2016-08-231-7/+1
|
* Fix performance regression in `TimeWithZone#to_time`Ryan De Villa2016-08-231-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A performance regression was introduced by commit b79adc4323ff289aed3f5787fdfbb9542aa4f89f from Rails 4.0.0.beta1, in which `TimeWithZone#to_time` no longer returns a cached instance attribute but instead coerces the value to `Time`. This coerced value is not cached, and recomputation degrades the performance of comparisons between TimeWithZone objects. See https://github.com/rails/rails/commit/b79adc4323ff289aed3f5787fdfbb9542aa4f89f#diff-3497a506c921a3a3e40fd517e92e4fe3R322 for the change in question. The following benchmark, which reverts the change linked above, demonstrates the performance regression: require 'active_support/time' require 'benchmark/ips' utc = Time.utc(2000, 1, 1, 0) time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)'] twz = ActiveSupport::TimeWithZone.new(utc, time_zone) twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC']) patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do def to_time utc end end patched_twz = patchedTimeWithZone.new(utc, time_zone) patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC']) Benchmark.ips do |x| x.report("comparison out of the box") { twz <=> twz2 } x.report("comparison reverting to_time") { patched_twz <=> patched_twz2 } x.compare! end The results, when run in rails-dev-box, are as follows: Warming up -------------------------------------- comparison out of the box 24.765k i/100ms comparison reverting to_time 57.237k i/100ms Calculating ------------------------------------- comparison out of the box 517.245k (± 4.7%) i/s - 2.600M in 5.038700s comparison reverting to_time 2.624M (± 5.0%) i/s - 13.050M in 4.985808s Comparison: comparison reverting to_time: 2624266.1 i/s comparison out of the box: 517244.6 i/s - 5.07x slower The change made to run the benchmark, however, is not possible, as it would undo the intent to standardize the return value of `to_time` to `Time` in the system timezone. Our proposed solution is to restore the caching behaviour of `to_time` as it existed prior to the change linked above. Benchmark of our solution: require 'active_support/time' require 'benchmark/ips' patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do def to_time @to_time ||= super end end utc = Time.utc(2000, 1, 1, 0) time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)'] twz = ActiveSupport::TimeWithZone.new(utc, time_zone) twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC']) patched_twz = patchedTimeWithZone.new(utc, time_zone) patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC']) Benchmark.ips do |x| x.report("TimeWithZone comparison - existing implementation") { twz <=> twz2 } x.report("TimeWithZone comparison - caching implementation") { patched_twz <=> patched_twz2 } x.compare! end Results in rails-dev-box: Warming up -------------------------------------- TimeWithZone comparison - existing implementation 26.629k i/100ms TimeWithZone comparison - caching implementation 59.144k i/100ms Calculating ------------------------------------- TimeWithZone comparison - existing implementation 489.757k (± 4.2%) i/s - 2.450M in 5.011639s TimeWithZone comparison - caching implementation 2.802M (± 5.3%) i/s - 13.958M in 4.996116s Comparison: TimeWithZone comparison - caching implementation: 2801519.1 i/s TimeWithZone comparison - existing implementation: 489756.7 i/s - 5.72x slower
* Add three new rubocop rulesRafael Mendonça França2016-08-161-1/+1
| | | | | | | | Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
* code gardening: removes redundant selfsXavier Noria2016-08-081-1/+1
| | | | | | | | | 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.
* applies remaining conventions across the projectXavier Noria2016-08-061-1/+0
|
* applies new string literal convention in activesupport/libXavier Noria2016-08-061-9/+9
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Add :weeks to the list of variable duration partsAndrew White2016-08-031-1/+1
| | | | | | | | Since 434df00 week durations are no longer converted to days. This means we need to add :weeks to the parts that ActiveSupport::TimeWithZone will consider being of variable duration to take account of DST transitions. Fixes #26039.
* Make getlocal and getutc always return instances of TimeAndrew White2016-04-231-8/+7
| | | | | | | | | | | | | | | Previously these methods could return either a DateTime or a Time depending on how the ActiveSupport::TimeWithZone instance had been constructed. Changing to always return an instance of Time eliminates a possible stack level too deep error in to_time where it was wrapping a DateTime instance. As a consequence of this the internal time value is now always an instance of Time in the UTC timezone, whether that's as the UTC time directly or a representation of the local time in the timezone. There should be no consequences of this internal change and if there are it's a bug due to leaky abstractions.
* Add compatibility for Ruby 2.4 `to_time` changesAndrew White2016-04-231-6/+2
| | | | | | | | | | | | | | | 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.
* Fix the example given in the documentation for TimeWithZone#-Phil Ross2015-10-291-4/+4
| | | | | | | The stated value of `now` would actually give the same result for `now - 24.hours` and `now - 1.day`. Use an alternative value for `now` that demonstrates the difference between subtracting `24.hours` and `1.day`.
* Add documentation for TimeWithZone #ago and #advance.Phil Ross2015-10-291-0/+38
|
* Expand support for ActiveSupport::TimeWithZone#utc?David Celis2015-10-151-1/+1
| | | | | | | | | | | | | | | | | Currently, ActiveSupport::TimeWithZone#utc? simply runs a check to see if the linked ActiveSupport::TimeZone's name is "UTC". This will only return true for ActiveSupport::TimeZone["UTC"], but not for time zones such as "Etc/UTC", "Etc/Universal", or other time zones that are aliases for UTC. Interestingly enough, ActiveSupport::TimeWithZone#utc? is also aliased as #gmt? but will return false for the "GMT" timezone (along with other TZInfo aliases for GMT). Instead of running a simple check on the TimeZone name, we can rely on the underlying TZInfo::TimezonePeriod and TZInfo::TimezoneOffset which keep a record of of the offset's abbreviated name. The possibilities here for UTC time zones are `:UTC`, `:UCT`, and `:GMT`. Signed-off-by: David <me@davidcel.is>
* TimeWithZone#xmlschema should be able to display more than 6 digitsFumiaki MATSUSHIMA2015-09-301-5/+4
|
* minor typo fix [ci skip]Aditya Kapoor2015-09-261-1/+1
|
* Short-circuit `blank?` on date and time valuesAndrew White2015-09-211-0/+5
| | | | | | | 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
* fix wrong method used in the TimeWithZone#inspect method docs [ci skip]yuuji.yaginuma2015-09-101-1/+1
|
* Fixed to_datetime docs [ci skip]Ronak Jangir2015-08-261-2/+3
|
* Added docs for TimeWithZone [ci skip]Ronak Jangir2015-08-181-1/+10
|
* Fix `TimeWithZone#eql?` to handle `TimeWithZone` created from `DateTime`Roque Pinel2015-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | 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`.
* Require active_support/duration.Jimmy Cuadra2015-06-041-0/+1
| | | | | | | | 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.
* Improve ActiveSupport::TimeWithZone conversion to YAMLAndrew White2015-04-221-6/+7
| | | | | | | | | | | 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.
* Doc fix [ci skip]Sushruth Sivaramakrishnan2015-03-051-1/+1
|
* Remove some comments about Ruby 1.9 behaviorsRafael Mendonça França2015-01-041-2/+2
|
* Replace AS::TimeWithZone#since with alias to +claudiob2014-12-161-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!
* Merge branch 'master' of github.com:rails/docrailsVijay Dev2014-12-151-4/+32
|\
| * Add docs for AS::TimeWithZone + and -claudiob2014-12-041-4/+32
| | | | | | | | | | | | The example was taken from the commit message 676d6a6. [ci skip]
* | Add documentation to six AS::TimeWithZone methodsclaudiob2014-12-041-2/+23
|/ | | | [ci skip]
* Optimize TimeWithZoneTest#strftimePablo Herrero2014-10-271-10/+6
|
* Merge pull request #15421 from gchan/time_with_zone_precisionMatthew Draper2014-06-051-1/+1
|\ | | | | | | Fixed `ActiveSupport::TimeWithZone#-` so precision is not unnecessarily lost
| * Fixed `ActiveSupport::TimeWithZone#-` so precision is not unnecessarily lostGordon Chan2014-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Speed-up TimeWithZone to String conversionAndrey Chernih2014-05-271-0/+8
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ci skip] doc ActiveSupport::TimeWithZone#to_sschneems2014-05-091-2/+5
| | | Current docs are wrong. Does not accept strftime inputs.
* Maintain the current timezone in wrap_with_time_zoneAndrew White2014-01-311-7/+2
| | | | | | | Extend the solution from the fix for #12163 to the general case where `Time` methods are wrapped with a time zone. Fixes #12596.
* Make ActiveSupport::TimeWithZone#xmlschema consistentAndrew White2014-01-261-2/+2
| | | | | | 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.
* Add support for JSON time_precision to Time and DateTimeAndrew White2014-01-261-2/+1
|
* Rename subsecond_fraction_digits option to time_precisionAndrew White2014-01-261-1/+1
|
* Customize subsecond digits when encoding DateWithTimeParker Selbert2014-01-261-1/+2
| | | | | | | | | | | 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
* Maintain current timezone when changing time during DST overlapAndrew White2014-01-261-3/+9
| | | | | | | | | | | | | | 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.
* Fix AS::TimeWithZone#as_json docsBogdan Gusiev2013-11-071-4/+4
| | | | According to 28ab79d7c579fa1d76ac868be02b38b02818428a
* Keep sub-second resolution when wrapping a DateTime valueAndrew White2013-06-131-5/+1
| | | | | | | Add `DateTime#usec` and `DateTime#nsec` so that `ActiveSupport::TimeWithZone` keeps sub-second resolution when wrapping a `DateTime` value. Fixes #10855
* `TimeWithZone` raises `NoMethodError` in proper context.Yves Senn2013-03-181-0/+2
| | | | | | | | | 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.
* Added `ActiveSupport::TimeWithZone#to_r` for `Time#at` compatibility.stopdropandrew2013-02-241-0/+4
|
* Modify TimeWithZone#as_json to return 3DP of sub-second accuracy by default, ↵James Harton2013-01-311-1/+1
| | | | since it's allowed by the spec and is very useful.
* Standardise the return value of `to_time`Andrew White2013-01-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Add more documentation to TimeWithZoneMatthew Stopa2013-01-011-0/+14
| | | | [ci skip]
* copy edits [ci skip]Vijay Dev2013-01-011-4/+3
|
* Add documentation for TimeWithZone methodsMatthew Stopa2012-12-311-3/+19
|
* Add documentation for the TimeWithZone#dst? method.Matthew Stopa2012-12-311-0/+6
| | | | [ci skip]
* Deprecate obsolete Time to DateTime fallback methodsAndrew White2012-12-111-1/+1
| | | | | | | 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.
* Merge branch 'master' of github.com:lifo/docrailsVijay Dev2012-09-211-17/+24
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-06 03:45:54 +0000