DatePicker time-zone handling gap in Chakra UI v2.2–v2.8

First, verify which package you are actually using

Before designing around a missing timeZone prop, confirm the component's origin. Core Chakra UI v2.x (the @chakra-ui/react form set: Input, Select, Checkbox, Radio, PinInput, and so on) does not ship an official DatePicker. Date-picking in that ecosystem has historically come from community packages, and the Zag.js-based date machinery is associated with the later v3 line. So a "Chakra UI DatePicker v2.2–v2.8" is most likely a third-party Chakra-styled wrapper or a mislabeled dependency in package.json. That distinction matters: whether a timeZone prop will ever appear depends on the actual upstream project's roadmap, not on Chakra itself. Check the dependency name and its repository's issue tracker before planning around a future prop.

The underlying problem is real regardless of the package

A JavaScript Date is an epoch-millisecond instant with no zone attached; any picker built on date-fns without zone support formats that instant in the browser's local zone. A stored UTC value like 2026-10-12T12:00:00Z will therefore display as 08:00 for a user in New York (EDT) and 17:30 in Kolkata. No picker configuration changes this — the conversion has to happen at the boundary between your UTC-storing state and the picker's local-time view.

The recommended wrapper pattern

Encapsulate both conversions in a single component that keeps the picker's value/onChange contract intact and adds exactly one prop: timeZone. Internally, convert the stored UTC instant to zoned wall-clock time on the way in, and reverse it on the way out:

import { utcToZonedTime, fromZonedTime } from 'date-fns-tz';

function ZonedDatePicker({ value, onChange, timeZone, ...pickerProps }) {
  // value: a UTC instant (Date or ISO string) from your store
  const zonedValue = value ? utcToZonedTime(value, timeZone) : null;

  const handleChange = (localDate) => {
    // localDate is wall-clock time in timeZone; convert back to a UTC instant
    onChange(localDate ? fromZonedTime(localDate, timeZone) : null);
  };

  return <DatePicker value={zonedValue} onChange={handleChange} {...pickerProps} />;
}

This confines all zone logic to one tested unit, leaves the underlying picker's API surface untouched, and lets call sites pass an IANA zone string without knowing about date-fns-tz. Import only the two functions you need so tree-shaking limits the bundle cost.

Handle DST edges explicitly

Manual round-trips fail silently around DST transitions: a wall-clock time like 02:30 on spring-forward day in America/New_York does not exist, and 01:30 on fall-back day is ambiguous. Decide a policy (shift forward, reject, or surface a warning) and encode it in the wrapper rather than letting date-fns-tz's default behavior surprise you.

Verification

1. Render a known instant (2026-10-12T12:00:00Z) with the browser set to a non-UTC zone and confirm the displayed wall-clock hour matches the target zone, not the local one.
2. Unit-test the round trip — UTC in → picker change → UTC out — across a DST boundary (e.g., March and November in America/New_York).
3. Check package.json for the real picker package and version, then review its issue tracker for any planned timeZone prop.

Planning guidance

Treat the local-only design as final for anything on the v2.x line; feature additions there are unlikely, and Chakra's own date components moved to a different architecture in v3. A wrapper is the low-risk choice today and remains useful even if a native prop appears later, since your conversion policy (especially DST handling) stays under your control.