Premium Analytics: add the Month to date and Year to date periods

[louwie17]

Proposed changes

Adds the two periods the revised date-picker design lists and we have never shipped: Month to date and Year to date. Each joins the group of the window it pairs with — Month to date beside Last month, Year to date beside Last 12 months — on every surface the period menu serves.

#51835 flagged both under "Deliberately not here": "Month to date and Year to date appear in the design but are not presets we ship." That was a statement about what was built, not a decision against them, and no Linear issue asks for or rejects either. The prototype on UNI-754 shows both, which is what prompted this.

Worth a product opinion: nobody has explicitly asked for these two, and this puts them on the dashboard as well as the detail pages. Happy to drop it if the answer is "not for v1".

Neither one completes its running unit

last-12-months runs from the first of a month to the end of today, so anything measuring it in whole units — its length, the previous period — measures the completed window instead (completeToDateRange). Giving the two new to-date periods the same treatment is the obvious move and is wrong for both, so to-date-range.ts ends up untouched:

• Month to date, completed, measures as one month, and a one-month shift lands on a month of another length. Read on 8 March the previous period came back three days shorter than the eight days it mirrors; on 15 February, three days longer.
• Year to date, completed, measures as twelve months, and a twelve-month shift crosses years of unequal length. Read on 1 January 2028 the previous period came back inverted — from after to — and on 1 January 2025 it put three days against one.

Read as they stand, both shift by their own day count and stay equal. Year over year is unaffected either way: previous-year shifts the dates as read, so Year to date still compares against the same days a year earlier. Both failures have regression tests.

A seam that stopped short

The panel's seam is the calendar's border-inline-start, and the panel aligned both halves to its start, so the border only ever spanned the calendar. Two more rows make the list the taller half for the first time (483px against the calendar's 460px), leaving Custom range with no seam beside it. Stretching both halves gives the border the panel's height whichever side is taller.

This is not reachable on trunk — the calendar is always at least as tall as today's list, at wide and narrow viewports alike — so there is no changelog entry for it.

Screenshots

Period menu, against trunk:

Before	After

The seam, with Custom range open (note the divider stopping above the bottom-left corner):

Before	After

Related product discussion/links

• Follows Premium Analytics: offer the whole period menu on the post and video detail pages #52087, which fixed UNI-754 and is merged.
• WOOA7S-2025 carries the dropdown design; Premium Analytics: add the date period dropdown #51835 is where both periods were noted as unshipped.
• Last 90 days and Last 365 days remain the mirror case — we ship them and the design does not list them — and are untouched here.

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

No.

Testing instructions

Build the dashboard: jetpack build --deps packages/premium-analytics, then open Premium Analytics (wp-admin/admin.php?page=jetpack-premium-analytics-wp-admin).

• The period menu now carries Month to date next to Last month and Year to date next to Last 12 months, on the dashboard and on a post's or video's detail page.
• Pick Month to date: the range runs from the 1st of this month to today. Year to date: from 1 January.
• On the dashboard, pick Month to date, turn on Compare, and check Previous period covers the same number of days as the selection — worth trying in a month whose predecessor is a different length (March after February is the sharpest).
• Same again with Year to date; Previous year should give the same days a year earlier.
• Open Custom range on the dashboard: the divider between the list and the calendar runs the full height of the panel, past Custom range.

pnpm run test in projects/packages/premium-analytics passes (3184 tests), as does pnpm run test-tz (the Tokyo / Los Angeles matrix).

🤖 Generated with Claude Code

https://claude.ai/code/session_015eDqAWndvFNBrBRdKcsYus

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the add/pa-month-and-year-to-date branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/pa-month-and-year-to-date

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/pa-month-and-year-to-date

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[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!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: October 6, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Premium Analytics plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/premium-analytics/packages/datetime/src/presets/primary.ts	82/82 (100.00%)	0.00%	0 💚
projects/packages/premium-analytics/packages/datetime/src/presets/types.ts	28/28 (100.00%)	0.00%	0 💚

Full summary · PHP report · JS report

[chihsuan]

Thanks for this @louwie17! These feel worth having for v1, the prototype has them. approving. 👍

I did notice that on 30 June, Year to date steps back a day short and hides the forward arrow. #52108 removes the arrows entirely though, so probably no need to address.

Separately, Claude Code found that Year to date with Same period in <year> does not start on 1 January around leap years. Read in 2028 it starts on 31 December 2026, and the label reads Same period in 2026. 2026 and 2027 are clean, so nothing shows today. Pre-existing and untouched here, so I filed it as follow-up (UNI-767), but the description says year over year is unaffected.

[chihsuan]

nit: just for consistency, should these two be re-exported from the package barrels too? The other presets are.

[louwie17]

Good catch — done in c6a7ec4. Both now sit in presets/index.ts and datetime/src/index.ts in their menu positions, next to PRESET_LAST_MONTH and PRESET_LAST_12_MONTHS.

The base branch was changed.