633cc1283b
Date.new(...) does not take into account the current timezone, while other
parts of the application do. By default always parsing any date with the
default timezone and converting the resulting Time to Date would prevent
this kind of issues
DateTime.parse(...).in_time_zone gives an unexpected result, as the
DateTime.parse(...) will create a DateTime with +0000 time zone and the
`in_time_zone` will modify the DateTime to adjust to the default zone.
Maybe its better explained with an example, using 'Lima' as timezone:
DateTime.parse("2015-01-01")
> Thu, 01 Jan 2015 00:00:00 +0000
DateTime.parse("2015-01-01").in_time_zone
> Wed, 31 Dec 2014 19:00:00 -05 -05:00
And that's not the desired date but the previous day!
37 lines
1.2 KiB
Ruby
37 lines
1.2 KiB
Ruby
require 'rails_helper'
|
|
|
|
describe Ahoy::DataSource do
|
|
describe '#build' do
|
|
before do
|
|
time_1 = Time.zone.local(2015, 01, 01)
|
|
time_2 = Time.zone.local(2015, 01, 02)
|
|
time_3 = Time.zone.local(2015, 01, 03)
|
|
|
|
create :ahoy_event, name: 'foo', time: time_1
|
|
create :ahoy_event, name: 'foo', time: time_1
|
|
create :ahoy_event, name: 'foo', time: time_2
|
|
create :ahoy_event, name: 'bar', time: time_1
|
|
create :ahoy_event, name: 'bar', time: time_3
|
|
create :ahoy_event, name: 'bar', time: time_3
|
|
end
|
|
|
|
it 'works without data sources' do
|
|
ds = described_class.new
|
|
expect(ds.build).to eq x: []
|
|
end
|
|
|
|
it 'works with single data sources' do
|
|
ds = described_class.new
|
|
ds.add 'foo', Ahoy::Event.where(name: 'foo').group_by_day(:time).count
|
|
expect(ds.build).to eq :x => ["2015-01-01", "2015-01-02"], "foo" => [2, 1]
|
|
end
|
|
|
|
it 'combines data sources' do
|
|
ds = described_class.new
|
|
ds.add 'foo', Ahoy::Event.where(name: 'foo').group_by_day(:time).count
|
|
ds.add 'bar', Ahoy::Event.where(name: 'bar').group_by_day(:time).count
|
|
expect(ds.build).to eq :x => ["2015-01-01", "2015-01-02", "2015-01-03"], "foo" => [2, 1, 0], "bar" => [1, 0, 2]
|
|
end
|
|
end
|
|
end
|