Fix registration closed error caused by timezone mismatch in event form

[Copilot]

What is the goal of this PR and why is this important?

This PR fixes a bug where events were incorrectly showing "Registration closed" even when the registration_close_date was in the future. The issue was caused by a timezone mismatch in the event form that caused registration dates to shift into the past after users saved event edits.

How did you approach the change?

Root Cause: The event form displayed UTC times from the database without converting to the user's local timezone. When users saved the form (even without changes), Rails interpreted the datetime-local values as being in the user's timezone, causing the stored times to shift. For example, a Pacific timezone user would see a date shift by 8 hours into the future, making it appear that registration had already closed.

Solution: Modified app/views/events/_form.html.erb to explicitly use current_user.time_zone for timezone conversion on all three datetime fields (start_date, end_date, registration_close_date) before displaying them. This ensures:

1. Times are displayed in the user's local timezone (not UTC)
2. When saved, times remain consistent and don't shift
3. The existing registerable? logic works correctly
4. The code is explicit about where the timezone value comes from

Changed from using Time.zone (which relies on around_action in ApplicationController) to directly using current_user&.time_zone || "UTC" for better clarity and explicitness.

Example: A registration date stored as 2026-03-15 20:00 UTC now correctly displays as 2026-03-15T12:00 for Pacific timezone users (12 PM Pacific) instead of 2026-03-15T20:00, preventing the date shift that occurred on save.

Anything else to add?

Testing:

• Added new spec spec/views/events/_form_timezone_spec.rb to verify timezone conversion
• Updated test spec to remove Time.zone mocking since we now use current_user.time_zone directly
• Code review completed and feedback addressed
• CodeQL security scan passed with no vulnerabilities

The fix directly references the user's time_zone attribute rather than depending on the around_action to set Time.zone, making the code more explicit and self-documenting.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[maebeale]

@copilot try again

[Copilot]

@copilot try again

Fixed in commit 5af20b4. The issue was a timezone mismatch in the event form.

The Problem:
When editing events, the form displayed UTC times from the database without converting to the user's local timezone. When users saved the form, Rails interpreted those times as being in their local timezone, causing the date to shift (e.g., 8 PM UTC became 4 AM UTC the next day for Pacific users). This made registration dates appear to have passed when they hadn't.

The Fix:
Added .in_time_zone(Time.zone) to convert database UTC times to the user's timezone before displaying in the form. Now times are displayed correctly and remain consistent when saved.

Changed in app/views/events/_form.html.erb:

• start_date field
• end_date field
• registration_close_date field

Example: A registration close date stored as 2026-03-15 20:00 UTC now correctly displays as 2026-03-15T12:00 for Pacific timezone users (12 PM Pacific) instead of 2026-03-15T20:00.

[maebeale]

@copilot should this be referencing the time_zone on user?

[Copilot]

@copilot should this be referencing the time_zone on user?

You're right! Changed in commit 8f5e323 to explicitly use current_user&.time_zone || "UTC" instead of relying on Time.zone. This is more explicit and makes it clear where the timezone value comes from. The code now directly references the user's time_zone attribute rather than depending on the around_action to set Time.zone.