Premium Analytics: resolve full ISO Stats dates to the site timezone

[kangzj]

Why this matters

The premium-analytics Stats data layer accepts full ISO from/to dates (so callers can drive Stats and Woo report hooks from the same date range), but the Stats backend interprets date boundaries in the site timezone. Before this change, an offset-bearing range like 2026-06-23T23:00:00-08:00 was reduced with a naive split('T')[0], keeping whatever offset the string carried — so at day boundaries the request landed on the wrong calendar day and returned data for the wrong day.

Proposed changes

• reportParamsToStatsQueryParams() now resolves offset-bearing from/to (Z / ±hh:mm) into the site timezone before reducing them to the date-only range the Stats backend expects. Date-only and timezone-naive inputs pass through unchanged.
• Added an optional timezone argument (defaults to getSiteTimezone()) so the conversion is unit-testable without mocking the core-data store.
• Hardened getDaysBetweenInclusive() to tolerate full ISO inputs (drops any time component) so a future caller can't silently regress the day count.

Related product discussion/links

• WOOA7S-1580
• Follow-up to the Stats proxy data layer work (WOOA7S-1571): Premium Analytics: add Stats proxy foundation #49775, Premium Analytics: add Stats traffic normalizers #49776, Premium Analytics: add Stats traffic queries #49777, Premium Analytics: add Stats traffic hooks #49778

Does this pull request change what data or activity we track or use?

No. It only corrects how an existing date range is normalized before it is sent to the Stats API.

Testing instructions

• cd projects/packages/premium-analytics && pnpm test packages/data/src/utils/__tests__/stats-params.test.ts
• Confirm the new cases pass:
  • An offset-bearing range that crosses midnight relative to the site timezone shifts to the correct calendar day (e.g. 2026-06-23T23:00:00-08:00 with site TZ +05:30 → 2026-06-24).
  • The end date is treated as an inclusive calendar day.
  • Date-only and timezone-naive inputs are unchanged.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!