🐛 Fixed post analytics missing first-day traffic on later days

[troyciesco]

ref ONC-1771

Post analytics was calculating the publish-date range from elapsed hours, while the chart query dates are calendar-day based. This meant posts could lose their publication-day traffic whenever the current time was earlier than the original publish time.

So if you published on Monday at 11am, you'd have the following:

• Monday: you'd see stats all day
• Tuesday before 11am: you'd only see Tuesday stats
• Tuesday after 11am: you'd correctly see Tuesday and Monday
  and so on

This PR updates the range calculation to count inclusive calendar days in the same timezone used by the chart date query, so the publish day is always included.

Before

Analytics overview	Post analytics
Shows 115 views for the post.	Shows only 15 unique visitors: 10 on 5/27 and 5 on 5/28. The 100 visitors from publish day, 5/26, are missing.

The control renders properly, however. See analytics overview above: we expect 90, we get 90 on post analytics

After

Post analytics
Correctly shows data for all 3 days, including publish day.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 73606763-0298-45f7-a574-a9e43fc4626e

📥 Commits

Reviewing files that changed from the base of the PR and between c7d27ac and 625c052.

📒 Files selected for processing (2)

• apps/shade/src/lib/app-utils.ts
• apps/shade/test/unit/utils/utils.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• apps/shade/src/lib/app-utils.ts

---

Walkthrough

This PR refactors getRangeForStartDate to compute inclusive calendar-day ranges using moment-timezone instead of millisecond Date arithmetic. It resolves the runtime IANA timezone, computes publishedDate and today as startOf('day') moments in that timezone, and sets the range count from today.diff(publishedDate, 'days') + 1 (minimum 1). Tests were added with Vitest fake timers to verify inclusive counting relative to publish time-of-day and the formatted startDate.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main bug fix: post analytics missing first-day traffic on later days, which directly matches the changeset's purpose of fixing the publish-date range calculation.
Description check	✅ Passed	The description thoroughly explains the bug, provides detailed before/after screenshots with specific metrics, and directly relates to the changeset's changes to getRangeForStartDate calculation logic.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ONC-1771_pub-date-stats

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/shade/test/unit/utils/utils.test.ts`:
- Around line 135-152: The tests for
getRangeForStartDate/getRangeDates/formatQueryDate are timezone-dependent and
can fail in non-US timezones; update the two specs to remove hard-coded
expectations by either (a) choosing start/publish instants that are unambiguous
in all timezones (e.g., use UTC-aligned times like '2026-05-26T12:00:00Z' and
set system time with vi.setSystemTime(new Date('2026-05-28T09:00:00Z'))), or (b)
compute the expected day/range dynamically using the test runtime zone
(Intl.DateTimeFormat().resolvedOptions().timeZone) and then assert against that
computed expected value; modify the tests referencing getRangeForStartDate,
getRangeDates, and formatQueryDate to implement one of these approaches so
assertions are robust across timezones.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ea199793-66c5-4a1f-81ca-34f10837cbcc

📥 Commits

Reviewing files that changed from the base of the PR and between 590f4f9 and c7d27ac.

📒 Files selected for processing (2)

• apps/shade/src/lib/app-utils.ts
• apps/shade/test/unit/utils/utils.test.ts

[coderabbitai]

Actionable comments posted: 0

[EvanHahn]

Clean.