Repository navigation
Conversation
Cfp#open? compared the CFP period against Date.current and Cfp#remaining_days defaulted to Date.today, both of which resolve in the server timezone. A conference in a different timezone therefore opened and closed its call for papers at the wrong moment: with the server on UTC and the conference in Pacific/Auckland, a CFP starting on the 2nd was still reported closed for the first 12 hours of the 2nd, and one ending on the 1st stayed open for those same 12 hours. Resolve today in the conference timezone instead, reusing the Time.find_zone idiom already used by Conference#current_conference_day.
m-altaifi
force-pushed
the
fix/cfp-conference-timezone
branch
from
September 1, 2026 22:03
db03230 to
52e9a67
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2769.
Cfp#open?compared the CFP period againstDate.current, which resolves in the server timezone rather than the conference's.Cfp#remaining_dayshad the same defect one step worse — it defaulted toDate.today, which ignoresTime.zoneentirely.So for any conference whose timezone differs from the server's, the call for papers opened and closed at the wrong moment. With the server on UTC and the conference in
Pacific/Auckland(UTC+12), during the first 12 hours of the 2nd the conference is on the 2nd while the server is still on the 1st, so a CFP starting on the 2nd was still reported closed, and a CFP ending on the 1st stayed open. It opened late and closed late, by the size of the offset. The "N days remaining" counter shown on the CFP pages was off by one over the same window.Both now resolve today in the conference timezone, via a private
conference_todaythat reuses theTime.find_zone(timezone)idiom already used byConference#current_conference_day.I fixed
remaining_daysalongsideopen?because it is the same bug reached through a different method — it is displayed next to the CFP state inadmin/cfps,conferences/_call_for_*andproposals/_encouragement_text, so leaving it on the server clock would keep showing a counter that disagrees withopen?.Tests
spec/models/cfp_spec.rbgains a context that pins the conference toPacific/Aucklandand freezes the clock at2026-06-01 23:30 UTC— 11:30 on the 2nd in Auckland — so the server and the conference disagree about the date. It covers both directions: a CFP for the 2nd is open (the server would call it closed), a CFP for the 1st is closed (the server would call it open), andremaining_dayscounts from the conference's date. All three fail onmaster.The existing
#open?examples anchored their dates toDate.currentwhile the conference factory assigns a random timezone (Faker::Address.time_zone), so they would have become intermittently flaky once the comparison moved to the conference clock. They now anchor to the same timezone they assert against.Timecop was already declared in the
Gemfilefor this purpose but not yet used anywhere.I do not have a working Ruby/PostgreSQL environment on this machine, so I have not run the suite locally — I am relying on CI here and will follow up on anything it reports.