Skip to content

Daylight Savings Time issue in to_yaml specs #563

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nehresma opened this issue Dec 13, 2024 · 0 comments · May be fixed by #564
Open

Daylight Savings Time issue in to_yaml specs #563

nehresma opened this issue Dec 13, 2024 · 0 comments · May be fixed by #564

Comments

@nehresma
Copy link

nehresma commented Dec 13, 2024

There is a daylight savings time error that gets triggered in the to_yaml specs.

The specs in spec/examples/to_yaml_spec.rb all create Schedules using a Ruby time object (Time.new). This object of course doesn't respond to time_zone method, so the time object gets serialized as just a time string that includes the zone offset, rather than as a hash that includes the timezone name (which is what adds DST rule support).

This is easy to see and trigger on the command line. America/Phoenix does not observe DST, but America/New_York does, and is currently in standard time:

$ date
Fri Dec 13 01:52:03 PM EST 2024
$ TZ=America/Phoenix rspec spec/examples/to_yaml_spec.rb:80
Run options: include {:locations=>{"./spec/examples/to_yaml_spec.rb"=>[80]}}
.

Finished in 0.16943 seconds (files took 0.10325 seconds to load)
1 example, 0 failures

$ TZ=America/New_York rspec spec/examples/to_yaml_spec.rb:80
Run options: include {:locations=>{"./spec/examples/to_yaml_spec.rb"=>[80]}}
F

Failures:

  1) IceCube::Schedule to_yaml should be able to make a round-trip to YAML with .day_of_year
     Failure/Error:
       expect(schedule2.first(10).map { |r| r.to_s })
         .to eq(schedule1.first(10).map { |r| r.to_s })
     
       expected: ["2025-04-10 13:52:10 -0400", "2025-07-19 13:52:10 -0400", "2026-04-10 13:52:10 -0400", "2026-07-19 1...52:10 -0400", "2028-07-18 13:52:10 -0400", "2029-04-10 13:52:10 -0400", "2029-07-19 13:52:10 -0400"]
            got: ["2025-04-10 13:52:10 -0500", "2025-07-19 13:52:10 -0500", "2026-04-10 13:52:10 -0500", "2026-07-19 1...52:10 -0500", "2028-07-18 13:52:10 -0500", "2029-04-10 13:52:10 -0500", "2029-07-19 13:52:10 -0500"]
     
       (compared using ==)
     # ./spec/examples/to_yaml_spec.rb:88:in `block (2 levels) in <module:IceCube>'
     # ./spec/spec_helper.rb:76:in `block (3 levels) in <top (required)>'
     # ./spec/spec_helper.rb:75:in `block (2 levels) in <top (required)>'

Finished in 0.19318 seconds (files took 0.11404 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/examples/to_yaml_spec.rb:80 # IceCube::Schedule to_yaml should be able to make a round-trip to YAML with .day_of_year

The spec is already requiring activesupport/time, so I propose that we alter the to_yaml_spec.rb specs to use ActiveSupport::TimeWithZone times instead. This will make the specs stop failing half the year when they're run in local timezone that have DST rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant