import React from 'react';
import type { IsoDate } from './iso-date.js';
export type DatePickerSize = 'sm' | 'md' | 'lg';
export interface DatePickerProps {
    /** Field label. Required for a usable control — see `a11y.requires`. */
    label?: React.ReactNode;
    /** Helper text below the field. */
    description?: React.ReactNode;
    /** Replaces the helper text while the field is invalid — `isInvalid`, or its own bounds check. */
    errorMessage?: React.ReactNode;
    isInvalid?: boolean;
    isDisabled?: boolean;
    isReadOnly?: boolean;
    isRequired?: boolean;
    /** Matches Input's `Size` variant: Small, Medium, Large. */
    size?: DatePickerSize;
    /**
     * The selected date as `YYYY-MM-DD`. `null` means nothing is selected.
     *
     * Not a `Date` and not a timestamp — a calendar date has no time and no
     * timezone, so it cannot shift across midnight the way `new Date('2026-04-12')`
     * does for every reader west of Greenwich. A malformed value throws rather
     * than rendering an empty field.
     */
    value?: IsoDate | null;
    /** The initial date as `YYYY-MM-DD`, for an uncontrolled picker. */
    defaultValue?: IsoDate;
    /** Fires with `YYYY-MM-DD`, or `null` when the field is cleared. */
    onChange?: (value: IsoDate | null) => void;
    /** Earliest selectable date, `YYYY-MM-DD`. Earlier dates are unreachable. */
    minValue?: IsoDate;
    /** Latest selectable date, `YYYY-MM-DD`. */
    maxValue?: IsoDate;
    /**
     * Individual dates the calendar refuses — weekends, holidays, booked days.
     * Receives `YYYY-MM-DD`. Use `minValue`/`maxValue` for a continuous bound;
     * this is for the holes inside it.
     */
    isDateUnavailable?: (date: IsoDate) => boolean;
    /** Posts the value under this name, for an uncontrolled form. */
    name?: string;
    /** Accessible label for the button that opens the calendar. */
    calendarLabel?: string;
    className?: string;
    wrapperClassName?: string;
    id?: string;
}
/**
 * DatePicker — a segmented date field with a calendar attached.
 *
 * WHY NOT `<input type="date">`
 *
 * The native control is genuinely good on mobile and genuinely unusable as a
 * design system component on desktop: its calendar cannot be styled at all, it
 * cannot express an unavailable date that is not part of a continuous min/max
 * range, and Safari on macOS renders no calendar button whatsoever. A system
 * whose date field looks like a different control in every browser is not a
 * design system, so this rebuilds it — and pays for that by having to rebuild
 * the keyboard handling and the screen-reader semantics the native control gave
 * away for free. React Aria's `useDatePicker` is what builds them back.
 *
 * THE VALUE IS A STRING, THE DISPLAY IS NOT
 *
 * `value` is always `YYYY-MM-DD` in the Gregorian calendar. What the user SEES
 * is their own locale's field order and their own calendar system, resolved
 * from `Intl` — so a German reader edits DD.MM.YYYY and the value still comes
 * back as `2026-04-12`. See `iso-date.ts` for why the public type is not
 * react-aria's `CalendarDate`.
 *
 * THE FIELD IS EDITABLE WITHOUT THE CALENDAR, AND THAT IS THE POINT
 *
 * Typing a date is faster than clicking one for anybody who knows the date they
 * want, and paging a calendar back to a birth year is miserable. The segments
 * take digits and arrow keys directly; the calendar is for the cases where the
 * date is being chosen rather than recalled.
 */
export declare function DatePicker({ label, description, errorMessage, isInvalid, isDisabled, isReadOnly, isRequired, size, value, defaultValue, onChange, minValue, maxValue, isDateUnavailable, name, calendarLabel, className, wrapperClassName, id, }: DatePickerProps): React.JSX.Element;
export declare namespace DatePicker {
    var displayName: string;
}
//# sourceMappingURL=DatePicker.d.ts.map