Fix flaky spec around DST changes

[soniaconnolly]

We use Zonebie so we are impacted by Europe's changes into and out of Daylight Savings Time as well as ours. Days sometimes have 23 or 25 hours, so account for that in specs by counting time within(60) minutes.

Note that we are more than 3 days out from Europe's DST change now, so this test will no longer fail with European time zones - but it would have started failing next week with North American time zones.

Auxilliary note: I would like to make Zonebie print the timezone it is using for our specs to ease debugging of such issues.

[aduth]

As an alternative, could we freeze time to a specific point in time that we don't have to deal with changing DST?

Personally I find be_within to be a bit of a code smell, though this is less offensive to me than the ones we have that try to account for drift in milliseconds.

[mitchellhenke]

I'd agree. The test can be made to fail reliably with:

--- a/spec/jobs/get_usps_proofing_results_job_spec.rb
+++ b/spec/jobs/get_usps_proofing_results_job_spec.rb
@@ -47,6 +47,11 @@ RSpec.shared_examples 'enrollment_with_a_status_update' do |passed:,
     end
   end

+  before do
+    Time.zone = 'Europe/Vienna'
+    allow(Time.zone).to receive(:now).and_return(Time.zone.parse('2023-11-01T00:20:00Z'))
+  end
+

[jmhooper]

I am generally no fan of comments, but I'll suggest either a comment here to explain why we are going to 11/30 or a method that describes that behavior, e.g.

it 'logs a message with common attributes' do
  travel_to_stable_daylight_savings_period do
    # ...
  end
end

# ...

def travel_to_stable_daylight_savings_period
  travel_to Time.zone.parse('2023-11-30T10:00:00Z') { yield }
end

[soniaconnolly]

I added an explanatory variable in 8522000

[JackRyan1989]

LGTM! Thanks @soniaconnolly