RSpec 时间比较在本地失败，通过 CircleCI 和 Heroku

Question

My rspec test fails on local machine between 6:00pm and 6:59pm, but passes at before 5:59pm and after 7:00pm on the local machine,

It seems to pass on CircleCI and Heroku, but I do not know if CircleCI or Heroku fail at specific times.

I set my local computer time to UTC, and it seems @subscription.current_period_end is incorrect by 1 hour.

I suspect it has something to do with how my local machine handles the time vs CircleCi and Heroku. Any ideas how to address this issue?

Code:

def get_proration_date
  Time.zone.now.to_i
end

Application.rb

config.active_record.default_timezone = :utc
config.time_zone = "UTC"

Rspec

it "should create upcoming_invoice with existing plan for the next_month if there are no changes to subscription(Mock Version)", live: false do
  create_stripe_elements
  stripe_gold_plan
  @subscription = payment_gateway.create_subscription(plan: silver_plan, user: user,
                   coupon_id: @coupon.stripe_id, source_id_or_token: default_card_token)
  invoice = payment_gateway.upcoming_invoice_for_update_plan(subscription: @subscription, to_plan: silver_plan,
            coupon_id: "", proration_date: get_proration_date)
  expect(invoice.lines.total_count).to eql(1)
  expect(invoice.amount_due).to eql(silver_plan.amount)
  expect(invoice.total).to eql(silver_plan.amount)
  expect(Time.zone.at(invoice.next_payment_attempt)).to eql(@subscription.current_period_end)
  delete_stripe_elements
end

Error

Failure/Error: expect(Time.zone.at(invoice.next_payment_attempt)).to eql(@subscription.current_period_end)

   expected: 2020-09-27 00:20:20.000000000 +0000
        got: 2020-09-27 01:20:20.000000000 +0000
 
   (compared using eql?)
 
   Diff:
   @@ -1,2 +1,2 @@
   -Sun, 27 Sep 2020 00:20:20 UTC +00:00
   +Sun, 27 Sep 2020 01:20:20 UTC +00:00

Answer 1

Most likely you have a bug in time calculations, potentially a time zone-related one.

Fire up pry or byebug on your local machine when the time comparison fails in the test and figure out which time is the correct one. Then figure out why the other time is wrong and fix that.

Answer 2

Suggest that you always store everything as UTC. Log timestamps, payment timestamps, audit dates, whatever. Do all your date and time calculations and intervals using the UTC values. That way you never ever have an issue with figuring out what happened, and the order in which it happened, even when your users are in different time zones, or they check out their shopping cart at 01:59:59 on the morning when you switch out of daylight saving time in the autumn. If you have a requirement to display dates and times to your users, this is a presentation issue and you can always convert the UTC values to their local timezone values for display purposes.

Answer 3

It was a stripe issue. They do not finalize an invoice until 1 hour after invoice is created, hence I needed to add an hour. @subscription.current_period_end+1.hour