Skip to content

Fix live-tracking indicator using server time zone for daytime check#358

Merged
gesteves merged 2 commits into
mainfrom
claude/event-live-tracking-tag-bug-Nbfmy
Jun 7, 2026
Merged

Fix live-tracking indicator using server time zone for daytime check#358
gesteves merged 2 commits into
mainfrom
claude/event-live-tracking-tag-bug-Nbfmy

Conversation

@gesteves

@gesteves gesteves commented Jun 7, 2026

Copy link
Copy Markdown
Owner

The bug

The "Live tracking" indicator (event_live_tracking_tag in api/app/helpers/events_helper.rb) only highlights and pulses while an event is_in_progress?, which requires is_daytime? to be true. In the events context there's no @weather, so is_daytime? (and is_evening?) fell back to the wall clock using Time.now — the server's system zone, which is UTC in production on fly.io — rather than the event location's local time.

So at 2:00 PM in San Francisco (UTC-7 → 21:00 UTC), now.hour was 21, the >= 6 && < 18 daytime check failed, and the icon never switched to its live/pulsing state. (The weather-present branch was fine — it compares absolute instants — only the no-forecast .hour fallback was wrong.)

The fix

Read the fallback clock in the location's timezone via current_time (Time.current.in_time_zone(location_time_zone)) in both is_daytime? and is_evening?. The absolute-instant sunrise/sunset comparisons are unchanged in meaning.

Specs and comments that had encoded the old system-zone fallback are updated: the no-weather daytime/evening fallback test now freezes a fixed UTC instant and asserts against the Denver-local hour, so it's deterministic regardless of where the suite runs.

Testing

  • spec/helpers/weather_helper_spec.rb + spec/helpers/events_helper_spec.rb: 114 examples, 0 failures.
  • Full suite: the only failures are 5 pre-existing plausible_pageviews_spec cache-header assertions, unrelated to this change (confirmed failing on the base branch).

https://claude.ai/code/session_01PNfLfKdfrvvM5jTWYT9WQc


Generated by Claude Code

`event_live_tracking_tag` highlights/pulses an event only while it's
"in progress", which requires `is_daytime?` to be true. With no `@weather`
in the events context, `is_daytime?`/`is_evening?` fell back to `Time.now`,
i.e. the server's system zone (UTC in production), instead of the location's
local time. At 2pm in a UTC-7 location that's 21:00 UTC, so the daytime
check failed and the icon never went live.

Read the fallback clock in the location's timezone via `current_time`, and
update the specs/comments that encoded the old system-zone behavior.
@netlify

netlify Bot commented Jun 7, 2026

Copy link
Copy Markdown

Deploy Preview for giventotri canceled.

Name Link
🔨 Latest commit 5d65035
🔍 Latest deploy log https://app.netlify.com/projects/giventotri/deploys/6a25df7bf52ddf0008dbfa09

The "in progress" check (which highlights and pulses the Live tracking link)
depends on it being daytime. We already fetch race-day weather for the
featured event — the only event whose tracking tag renders — so prefer its
own sunrise/sunset over the owner's-location clock.

`is_in_progress?` now takes the featured event's weather presenter and, when
its sun times are present, treats the event-day sunrise..sunset window as the
source of truth: covering "now" means it's both the event's day and daytime at
the event's location (the sun times are absolute instants, so the comparison
is timezone-independent). It falls back to today-and-daytime in the owner's
timezone when that weather isn't available. The tag and the upcoming-races
partial thread the presenter through.
@gesteves gesteves merged commit 2e2be76 into main Jun 7, 2026
8 checks passed
@gesteves gesteves deleted the claude/event-live-tracking-tag-bug-Nbfmy branch June 7, 2026 21:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants