Date Range Picker in React: Calendar Grid, Presets, Time Zone

Why Date Range Pickers Are So Hard to Get Right

Most developers underestimate date range pickers. They look simple — two inputs, a calendar, done. Then you hit locale formatting, keyboard navigation, time zone offsets, preset ranges, and mobile tap targets, and suddenly you're three days deep rewriting a component that should have taken an afternoon. It's one of those UI problems that seems solved until you actually solve it.

The core tension is that a date range has three distinct states at any moment: no selection, partial selection (start picked, end pending), and complete selection. Your calendar grid has to render all three without visual ambiguity, respond to hover to show the in-progress range, and not blow up when the user picks an end date earlier than the start date. Honestly, state management alone is 40% of the work here.

There's also the time zone problem. JavaScript's Date object operates in local time by default, which means a user in New York selecting "today" gets midnight America/New_York, but your server might store UTC and your analytics pipeline might aggregate in America/Los_Angeles. If you don't handle this explicitly from day one, you'll ship off-by-one-day bugs that are miserable to debug. We'll cover that specifically in the time zone section.

This guide builds a complete solution: a reusable DateRangePicker with a dual-month calendar grid, preset shortcuts, and proper time zone handling. No dependencies beyond React 18+ and the Intl API. Let's go.

State Model: The Only Data You Actually Need

Before writing any JSX, nail the state shape. A date range picker needs exactly four pieces of state: startDate, endDate, hoverDate, and visibleMonth. That's it. Everything else — which cells are highlighted, whether the range is valid, what the input displays — derives from these four values at render time.

// types.ts
export type DateRange = {
  start: Date | null;
  end: Date | null;
};

export type PickerState = {
  range: DateRange;
  hoverDate: Date | null;
  /** First day of the left-hand calendar month */
  visibleMonth: Date;
};

The selection flow is a simple state machine. On first click: set start, clear end. On hover while start is set and end is null: update hoverDate so you can shade the preview range. On second click: if the clicked date is before start, swap them (never leave the user with an invalid range). Once end is set, hoverDate becomes irrelevant until they start over. Worth noting: never store derived state like isInRange(day) — compute it inline during render from start, end, and hoverDate. Stale derived state is a classic source of flicker bugs.

// useDateRangePicker.ts
import { useReducer } from 'react';
import type { DateRange, PickerState } from './types';

type Action =
  | { type: 'DAY_CLICK'; date: Date }
  | { type: 'DAY_HOVER'; date: Date }
  | { type: 'MOUSE_LEAVE' }
  | { type: 'NAV'; direction: 1 | -1 }
  | { type: 'SET_PRESET'; range: DateRange };

function reducer(state: PickerState, action: Action): PickerState {
  switch (action.type) {
    case 'DAY_CLICK': {
      const { start, end } = state.range;
      // Starting fresh or restarting after full selection
      if (!start || end) {
        return { ...state, range: { start: action.date, end: null }, hoverDate: null };
      }
      // Completing the range — swap if necessary
      const [s, e] = action.date < start
        ? [action.date, start]
        : [start, action.date];
      return { ...state, range: { start: s, end: e }, hoverDate: null };
    }
    case 'DAY_HOVER':
      return state.range.start && !state.range.end
        ? { ...state, hoverDate: action.date }
        : state;
    case 'MOUSE_LEAVE':
      return { ...state, hoverDate: null };
    case 'NAV': {
      const d = new Date(state.visibleMonth);
      d.setMonth(d.getMonth() + action.direction);
      return { ...state, visibleMonth: d };
    }
    case 'SET_PRESET':
      return { ...state, range: action.range, hoverDate: null };
    default:
      return state;
  }
}

export function useDateRangePicker(initialMonth = new Date()) {
  const [state, dispatch] = useReducer(reducer, {
    range: { start: null, end: null },
    hoverDate: null,
    visibleMonth: new Date(initialMonth.getFullYear(), initialMonth.getMonth(), 1),
  });
  return { state, dispatch };
}

Using useReducer instead of multiple useState calls keeps transitions atomic. You can't get into a state where start is cleared but end still holds the old value because both fields update in the same dispatch cycle. This matters when you add presets later — a preset fires a single SET_PRESET action that sets both simultaneously.

Building the Calendar Grid

The grid is the visual core. A month view is always a 6×7 matrix (42 cells) — you pad the first row with days from the previous month and the last row with days from the next month to fill it out. That fixed size means your grid never jumps height between months, which drives users insane when it does.

// calendarUtils.ts
export function getMonthGrid(year: number, month: number): Date[] {
  // month is 0-indexed
  const firstDay = new Date(year, month, 1);
  const startOffset = firstDay.getDay(); // 0 = Sunday
  const cells: Date[] = [];

  // Pad with previous month
  for (let i = startOffset - 1; i >= 0; i--) {
    cells.push(new Date(year, month, -i));
  }
  // Current month
  const daysInMonth = new Date(year, month + 1, 0).getDate();
  for (let d = 1; d <= daysInMonth; d++) {
    cells.push(new Date(year, month, d));
  }
  // Pad to 42 cells
  while (cells.length < 42) {
    cells.push(new Date(year, month + 1, cells.length - startOffset - daysInMonth + 1));
  }
  return cells;
}

export function isSameDay(a: Date, b: Date): boolean {
  return a.getFullYear() === b.getFullYear()
    && a.getMonth() === b.getMonth()
    && a.getDate() === b.getDate();
}

export function isInRange(day: Date, start: Date | null, end: Date | null): boolean {
  if (!start || !end) return false;
  return day > start && day < end;
}

The CalendarMonth component renders one grid. For dual-month mode you render two side by side, with the right calendar always showing visibleMonth + 1. This means your navigation arrows only need to update visibleMonth — the right calendar derives automatically.

// CalendarMonth.tsx
import { getMonthGrid, isSameDay, isInRange } from './calendarUtils';
import type { DateRange } from './types';

const DAY_NAMES = ['Su', 'Mo', 'Tu', 'We', 'Th', 'Fr', 'Sa'];

interface CalendarMonthProps {
  year: number;
  month: number; // 0-indexed
  range: DateRange;
  hoverDate: Date | null;
  onDayClick: (d: Date) => void;
  onDayHover: (d: Date) => void;
}

export function CalendarMonth({
  year, month, range, hoverDate, onDayClick, onDayHover,
}: CalendarMonthProps) {
  const cells = getMonthGrid(year, month);
  const effectiveEnd = range.end ?? hoverDate;

  return (
    <div className="select-none">
      <p className="text-center font-semibold mb-3">
        {new Intl.DateTimeFormat('en-US', { month: 'long', year: 'numeric' })
          .format(new Date(year, month))}
      </p>
      <div className="grid grid-cols-7 gap-y-1">
        {DAY_NAMES.map(n => (
          <span key={n} className="text-center text-xs text-gray-400 pb-2">{n}</span>
        ))}
        {cells.map((day, i) => {
          const isCurrentMonth = day.getMonth() === month;
          const isStart = range.start ? isSameDay(day, range.start) : false;
          const isEnd = range.end ? isSameDay(day, range.end) : false;
          const inRange = range.start ? isInRange(day, range.start, effectiveEnd ?? range.start) : false;
          const isHoverEnd = hoverDate && !range.end ? isSameDay(day, hoverDate) : false;

          return (
            <button
              key={i}
              type="button"
              onClick={() => isCurrentMonth && onDayClick(day)}
              onMouseEnter={() => isCurrentMonth && onDayHover(day)}
              className={[
                'h-9 w-full text-sm rounded-full transition-colors',
                !isCurrentMonth && 'opacity-30 pointer-events-none',
                isStart || isEnd ? 'bg-indigo-600 text-white font-semibold' : '',
                inRange && !isStart && !isEnd ? 'bg-indigo-100 text-indigo-800 rounded-none' : '',
                isHoverEnd && !range.end ? 'bg-indigo-200 text-indigo-700 font-medium' : '',
                !isStart && !isEnd && !inRange && !isHoverEnd ? 'hover:bg-gray-100' : '',
              ].join(' ')}
            >
              {day.getDate()}
            </button>
          );
        })}
      </div>
    </div>
  );
}

One thing to watch: the rounded-none on in-range cells only looks right if you also tweak the start and end cells to be flat on one side (left edge for start, right edge for end). You can do this with rounded-l-full and rounded-r-full class combinations. It's 10 extra lines of conditional class logic but it's the difference between a calendar that looks built and one that looks bought. In practice, most teams skip this polish and users notice.

Preset Ranges: The Feature That Actually Gets Used

Look, users don't want to click a calendar to select "last 7 days". Presets are the reason date range pickers in analytics dashboards feel fast and the ones without feel like a tax form. Add them. They're 30 lines of code.

// presets.ts
export type Preset = {
  label: string;
  getRange: () => { start: Date; end: Date };
};

function startOfDay(d: Date): Date {
  return new Date(d.getFullYear(), d.getMonth(), d.getDate());
}
function endOfDay(d: Date): Date {
  return new Date(d.getFullYear(), d.getMonth(), d.getDate(), 23, 59, 59, 999);
}

export const DEFAULT_PRESETS: Preset[] = [
  {
    label: 'Today',
    getRange: () => { const t = new Date(); return { start: startOfDay(t), end: endOfDay(t) }; },
  },
  {
    label: 'Last 7 days',
    getRange: () => {
      const end = endOfDay(new Date());
      const start = startOfDay(new Date(Date.now() - 6 * 86_400_000));
      return { start, end };
    },
  },
  {
    label: 'Last 30 days',
    getRange: () => {
      const end = endOfDay(new Date());
      const start = startOfDay(new Date(Date.now() - 29 * 86_400_000));
      return { start, end };
    },
  },
  {
    label: 'This month',
    getRange: () => {
      const now = new Date();
      return {
        start: new Date(now.getFullYear(), now.getMonth(), 1),
        end: endOfDay(new Date(now.getFullYear(), now.getMonth() + 1, 0)),
      };
    },
  },
  {
    label: 'Last month',
    getRange: () => {
      const now = new Date();
      const y = now.getMonth() === 0 ? now.getFullYear() - 1 : now.getFullYear();
      const m = now.getMonth() === 0 ? 11 : now.getMonth() - 1;
      return {
        start: new Date(y, m, 1),
        end: endOfDay(new Date(y, m + 1, 0)),
      };
    },
  },
  {
    label: 'This year',
    getRange: () => {
      const y = new Date().getFullYear();
      return { start: new Date(y, 0, 1), end: endOfDay(new Date(y, 11, 31)) };
    },
  },
];

Render the preset list as a vertical sidebar to the left of the calendar grid on desktop, or as a horizontal scrollable row above it on mobile. When a preset fires, dispatch SET_PRESET and also snap visibleMonth to the month containing the preset's start date. Nothing is more disorienting than clicking "Last month" and having the calendar still show the current month.

Quick aside: if your product has domain-specific presets (fiscal quarters, billing cycles, sprint windows), just push extra Preset objects into the array. The shape is identical — a label and a zero-argument function that returns {start, end}. You can fetch server-defined presets and spread them in. Totally composable.

That said, don't auto-close the picker when a preset is selected if the user might want to tweak the dates afterward. Show a "Apply" button, or at minimum a 200ms delay before close so they can see what changed. Auto-closing on preset click is a UX trap that triggers a second open 30% of the time in user tests.

Time Zone Handling Without Losing Your Mind

Here's the actual hard part. JavaScript Date objects have no time zone — they're milliseconds since epoch. When you call new Date(2026, 8, 7) you get midnight local time, which serializes to different ISO strings depending on the user's browser locale. That's a bug waiting to ship.

The safest approach for a date range picker that sends data to a server is to output explicit UTC midnight values or ISO date strings with no time component. For most analytics and booking use cases you don't actually care about the time — just the date — so serialize to YYYY-MM-DD and let the server interpret it in the appropriate zone.

// tzUtils.ts

/** Serialize a Date to a YYYY-MM-DD string using LOCAL calendar date */
export function toLocalDateString(d: Date): string {
  const y = d.getFullYear();
  const m = String(d.getMonth() + 1).padStart(2, '0');
  const day = String(d.getDate()).padStart(2, '0');
  return `${y}-${m}-${day}`;
}

/**
 * If you need UTC midnight ISO (e.g. for APIs expecting epoch timestamps)
 * and the picker's dates represent the user's local calendar:
 */
export function toUTCMidnight(d: Date): string {
  return new Date(
    Date.UTC(d.getFullYear(), d.getMonth(), d.getDate())
  ).toISOString();
}

/**
 * Parse a YYYY-MM-DD string back to a local-midnight Date
 * Avoids the infamous 'off by one' from new Date('2026-09-07') which
 * gives UTC midnight, then shifts to local time.
 */
export function fromLocalDateString(s: string): Date {
  const [y, m, d] = s.split('-').map(Number);
  return new Date(y, m - 1, d);
}

The classic gotcha: new Date('2026-09-07') in a UTC-5 browser gives you 2026-09-06T19:00:00 locally — i.e., September 6th. Always use fromLocalDateString when parsing dates from server responses back into the picker. This single function has saved my team from a half-dozen production incidents. If your product needs to display dates in a *specific* named time zone (e.g., a hotel booking system showing America/New_York times regardless of user locale), reach for Intl.DateTimeFormat with the timeZone option for display, and store UTC offsets explicitly on the server side.

One more thing — if you're rendering in a Next.js 15+ app with server components, don't instantiate new Date() in server component code expecting it to reflect the user's local time. It'll use the server's time zone (almost certainly UTC). Keep all date construction client-side in this picker. A 'use client' directive on the root DateRangePicker component is the correct call.

Keyboard Navigation and Accessibility

This is the section most tutorials skip. Don't. A date picker that isn't keyboard accessible will fail accessibility audits, which matters more in 2026 than it did in 2020 — lawsuits over WCAG 2.1 AA compliance have been rising since 2022 and courts increasingly side with plaintiffs.

The ARIA pattern for a date grid is defined in the ARIA Authoring Practices Guide. The calendar grid should have role="grid" with role="row" and role="gridcell" on each cell. The currently focused date gets aria-selected="true" when it's within the range. The trigger button needs aria-haspopup="dialog" and the popover itself needs role="dialog" with aria-modal="true" and aria-label="Choose date range".

// Keyboard handler on each day button
const handleKeyDown = (e: React.KeyboardEvent, day: Date) => {
  const moves: Record<string, number> = {
    ArrowRight: 1,
    ArrowLeft: -1,
    ArrowDown: 7,
    ArrowUp: -7,
  };
  if (e.key in moves) {
    e.preventDefault();
    const next = new Date(day);
    next.setDate(next.getDate() + moves[e.key]);
    focusDate(next); // imperative focus via ref map
  }
  if (e.key === 'Enter' || e.key === ' ') {
    e.preventDefault();
    dispatch({ type: 'DAY_CLICK', date: day });
  }
  if (e.key === 'Escape') {
    closePopover();
  }
};

Focus management is the fiddly part. When the user presses Arrow keys and navigates across a month boundary, you need to update visibleMonth and then imperatively focus the new cell after the re-render. Use a ref map keyed by toLocalDateString(day) and a useEffect that fires when focusedDate changes. It's about 20 lines. Worth doing properly — it's what separates a component you'd ship in a design system from one you'd copy-paste and forget.

Putting It All Together and Styling Options

The final DateRangePicker wraps everything: trigger button, popover, two CalendarMonth components side by side, the presets sidebar, and the Apply/Cancel footer. Keep the popover in a position: absolute container with z-50 — don't use a portal unless you need to escape overflow clipping (like inside a card with overflow: hidden). Portals add complexity and break onClickOutside listeners.

// DateRangePicker.tsx (simplified shell)
export function DateRangePicker({
  value,
  onChange,
  presets = DEFAULT_PRESETS,
  timeZone = 'local',
}: DateRangePickerProps) {
  const { state, dispatch } = useDateRangePicker();
  const [open, setOpen] = useState(false);
  const rightMonth = new Date(
    state.visibleMonth.getFullYear(),
    state.visibleMonth.getMonth() + 1,
    1,
  );

  const handleApply = () => {
    if (state.range.start && state.range.end) {
      onChange({
        start: toLocalDateString(state.range.start),
        end: toLocalDateString(state.range.end),
      });
    }
    setOpen(false);
  };

  return (
    <div className="relative inline-block">
      <TriggerButton range={state.range} onClick={() => setOpen(v => !v)} />
      {open && (
        <div className="absolute top-12 left-0 z-50 flex bg-white border border-gray-200 rounded-2xl shadow-xl p-4 gap-6">
          <PresetList
            presets={presets}
            onSelect={range => dispatch({ type: 'SET_PRESET', range })}
          />
          <CalendarMonth
            year={state.visibleMonth.getFullYear()}
            month={state.visibleMonth.getMonth()}
            range={state.range}
            hoverDate={state.hoverDate}
            onDayClick={date => dispatch({ type: 'DAY_CLICK', date })}
            onDayHover={date => dispatch({ type: 'DAY_HOVER', date })}
          />
          <CalendarMonth
            year={rightMonth.getFullYear()}
            month={rightMonth.getMonth()}
            range={state.range}
            hoverDate={state.hoverDate}
            onDayClick={date => dispatch({ type: 'DAY_CLICK', date })}
            onDayHover={date => dispatch({ type: 'DAY_HOVER', date })}
          />
          <footer className="flex justify-end gap-2 pt-3 border-t border-gray-100">
            <button onClick={() => setOpen(false)} className="px-4 py-2 text-sm">Cancel</button>
            <button onClick={handleApply} className="px-4 py-2 text-sm bg-indigo-600 text-white rounded-lg">Apply</button>
          </footer>
        </div>
      )}
    </div>
  );
}

For styling, the component above uses plain Tailwind. If you want something with visual personality — neon borders on hover, glass-panel popover, cyberpunk grid lines — Empire UI has the design tokens and component primitives to make it trivial. Pair the calendar popover with a glassmorphism surface (backdrop-blur-md bg-white/10 border border-white/20) and suddenly your date picker looks like it belongs in a premium dashboard rather than a CRUD app.

On mobile you'll want to switch to a single-month view with a full-width bottom sheet. The breakpoint swap is one useMediaQuery hook and a conditional render. The touch target for each day cell should be at least 44px — the default h-9 (36px) you see in most examples fails iOS Human Interface Guidelines. Bump day cells to h-11 on mobile.

If you'd rather use an existing library as a base, react-day-picker v9 (released in 2024) has excellent accessibility and a clean headless API you can style freely. Wrap it in a compound component pattern and you get the same ergonomics as the custom build above with less maintenance surface. In practice, for most product teams the library approach is the right call — custom builds shine when you need deep visual control or unusual selection logic. Check the Empire UI blog for more component deep-dives.

FAQ

Read next