[PF-2296] Upgrade date-fns to latest v4.x

[azebich]

PF-2296

Description

Upgrade date-fns ^2.30.0 → ^4.1.0 and date-fns-tz ^2.0.0 → ^3.2.0
across the workspace. v2 is unmaintained, and @base-ui/react — the primitive
layer the kit is migrating to — peers date-fns: ^4.0.0, which v2 did not satisfy.

Two breaking changes, both verified against the installed packages:

• v3 removed submodule default exports — 10 sites. import isWeekend from 'date-fns/isWeekend' now resolves to undefined, so all 10 move to named
  imports from the barrel. The 7 sites already using the barrel are untouched.
• date-fns-tz v3 renamed its exports — 1 site. utcToZonedTime →
  toZonedTime. Confirmed a pure rename: identical results across 9 cases
  including both US DST transitions, +09:30 / +05:45 offsets and a date-line
  crossing. format and toDate are unchanged.

The peer trade-off — the part worth reviewing. react-day-picker@8.x peers
date-fns: ^2.28.0 || ^3.0.0 and no 8.x release admits v4, while @base-ui/react
peers ^4.0.0. No version satisfies both; Base UI wins, since react-day-picker v8
is end-of-life. The unsatisfied peer is recorded as a commented exception in
pnpm-workspace.yaml rather than left silent, and is verified safe —
react-day-picker reaches date-fns only through named barrel imports, and all 31
functions it uses are unchanged in v4.

This is lateral, not a regression: a consumer pnpm install already fails today on
v2 from the Base UI side (confirmed against master's versions). v4 flips which side
is unsatisfied — it fixes Base UI's conflict and introduces react-day-picker's. The
exception disappears with the react-day-picker v9+ migration, where date-fns stops
being a peer of that package entirely.

Also widens timezone test coverage from 7 tests to 37. The America/New_York case
declared -05:00 on a June date, when New York is -04:00 (EDT) — it landed an
hour past the boundary it appeared to probe and passed while testing nothing. Fixed,
and added both sides of midnight for Shanghai +08:00 and Los Angeles -08:00
(PST, winter date), plus the PDT and EST counterparts.

Not in scope: react-day-picker v9/v10 (tracked separately; it retires the peer
exception) and adopting v4's TZDate model — this is a like-for-like port.

How to test

• Temploy
• DatePicker → WithTimezone: switch timezone between Asia/Shanghai,
  America/Los_Angeles and Asia/Tokyo; confirm the input and the selected day
  agree and neither is a day off.
• Set a value near local midnight in a western zone and confirm the day shown is
  the local day, not the UTC day.
• Calendar stories: month navigation, range selection, disabled and indicated
  intervals — isWeekend, isSameMonth and format all changed import form here.
• Type a date into DatePicker's input; parse and isValid changed import form.
• Happo: no visual change expected, no rendering logic changed. Any diff needs
  triage.

Verified locally: pnpm typecheck and tsc -b exit 0 · full Jest suite 306 suites
/ 1441 tests / 274 snapshots pass with zero snapshot churn (up from 1411) · the new
timezone tests are mutation-tested, so they are not decorative — removing the
conversion, reversing its direction, and forcing a DST-blind fixed offset each fail
the expected cases · the @base-ui/react unmet-peer warning is gone from install
output · ESLint 0 errors, prettier clean. Cypress could not run locally (Electron
will not start in WSL2); DatePicker.spec.tsx and Calendar.spec.tsx are on CI.

Screenshots

No visual change intended — only import form, one rename and dependency ranges.

Before.	After.
n/a — no visual change expected	n/a — no visual change expected

Note on the changeset tier

patch, on the guidelines' "change which does not affect Picasso users" — no API
or behaviour change, matching how PF-2289 tiered its equivalent bump. But the
guidelines also make major mean "users need to take action", and a consumer may
now need --legacy-peer-deps for the react-day-picker peer (they arguably already
do, for Base UI). If you read that as new action, say so and I will rewrite it as
major. @topkit/analytics-charts and the repo root carry date-fns as a
devDependency, so neither needs a changeset.

Development checks

• Add changeset according to guidelines (if needed)
• Double check if picasso-tailwind-merge requires major update (check its README.md) — n/a, no styling changes
• Read CONTRIBUTING.md and Component API principles
• Make sure that additions and changes on the design follow Toptal's BASE design, and it's been already discussed with designers at #-base-core — n/a, no design change
• Annotate all props in component with documentation — n/a, no props changed
• Create examples for component — n/a, no new component or behaviour
• Ensure that deployed demo has expected results and good examples
• Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.
• Self reviewed
• Covered with tests (visual tests included) — timezone coverage extended from 7 to 37 tests across three code paths, mutation-verified. No snapshot churn.

Breaking change

Not a breaking change to any Picasso API — no codemod needed. See the changeset
tier note above.

• codemod is created and showcased in the changeset
• test alpha package of Picasso in StaffPortal

[changeset-bot]

🦋 Changeset detected

Latest commit: 9e95aeb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@toptal/picasso-calendar	Patch
@toptal/picasso-date-picker	Patch
@toptal/picasso	Patch
@toptal/picasso-forms	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

📖 Storybook Preview

🚀 Your Storybook preview is ready: View Storybook

📍 Preview URL: https://toptal.github.io/picasso/prs/5076/

This preview is updated automatically when you push changes to this PR.