import { DateRange, Matcher } from 'react-day-picker';
/**
 * Floating-ui offset (in px) between the trigger input and the popover.
 * Shared by `DateField` and `DateTimeField` so the popovers sit at the
 * same distance from their triggers.
 */
export declare const CALENDAR_POPOVER_OFFSET = 4;
/**
 * Floating-ui shift / size middleware padding (in px) — keeps the popover
 * away from the viewport edges by this amount when the size middleware
 * caps its `maxWidth`.
 */
export declare const CALENDAR_POPOVER_PADDING = 8;
export type SelectedValueLike = Date | Date[] | DateRange | undefined;
/**
 * Range-selection click resolver. react-day-picker's default `addToRange`
 * keeps a completed `{ from, to }` range and only moves one of its ends when
 * the user clicks again — so after picking a start and an end, clicking a new
 * start instead drags the existing end. That surprises users who expect a
 * fresh click to begin a new range.
 *
 * This normalises that: once a range is complete, the next click starts over
 * with `from` set to the clicked day and `to` cleared. While the range is
 * still being built (or empty), DayPicker's own result is passed through.
 *
 * @param computed - the range react-day-picker derived from the click
 * @param previous - the range that was selected before this click
 * @param clickedDay - the day the user just clicked
 */
export declare const resolveRangeSelection: (computed: SelectedValueLike, previous: SelectedValueLike, clickedDay: Date | undefined) => DateRange | undefined;
/**
 * Resolves the month the calendar should start on for any selection
 * shape. Used by both `DateField` (single / multiple / range Date(s)) and
 * `DateTimeField` (single Date or `{from, to}` range). For arrays the
 * earliest date wins; for ranges the `from` (or `to` if `from` is unset)
 * wins. Falls back to the explicit `fallback` and finally `new Date()`.
 */
export declare const getInitialMonth: (val: SelectedValueLike, fallback?: Date) => Date;
/**
 * Configuration for the `buildDisabledMatchers` helper. All fields are
 * forwarded as-is to react-day-picker. `shouldDisableMonth` /
 * `shouldDisableYear` are predicates passed to `DayPicker.disabled` to
 * disable a date when its month / year is "off limits".
 */
export interface DisabledMatcherInputs {
    disabled?: Matcher | Matcher[];
    minDate?: Date;
    maxDate?: Date;
    disablePast?: boolean;
    disableFuture?: boolean;
    shouldDisableMonth?: (date: Date) => boolean;
    shouldDisableYear?: (date: Date) => boolean;
}
/**
 * Composes a flat `Matcher[]` array from the date-field-style constraint
 * props. Returns an empty array when nothing is set, which lets the
 * caller pass `matchers.length ? matchers : undefined` straight through.
 */
export declare const buildDisabledMatchers: (inputs: DisabledMatcherInputs) => Matcher[];
/**
 * Field order + literal separators extracted from a locale's date format,
 * derived via `Intl.DateTimeFormat.formatToParts`. Used by parsers in
 * `DateField` (date-only) and `DateTimeField` (date + " HH:mm") to build
 * a regex that round-trips the displayed value in any locale.
 */
export interface LocaleDateParts {
    fieldOrder: ('day' | 'month' | 'year')[];
    separators: string[];
}
/**
 * Extract the date-portion field order and literal separators from a
 * `dateFormatter`. The reference date `Dec 31, 2099` is used because all
 * three components are unambiguously two-digit (day, month) / four-digit
 * (year) values, so each `formatToParts` entry is unambiguous.
 */
export declare const getLocaleDateParts: (dateFormatter: Intl.DateTimeFormat) => LocaleDateParts;
/**
 * Build the date-portion of a parsing regex from the locale's field
 * order and separators. Caller appends time / range separators as needed
 * — DateField uses `^${datePart}$`, DateTimeField uses `^${datePart}\s+(\d{2}):(\d{2})$`.
 */
export declare const buildDateRegexSource: ({ fieldOrder, separators }: LocaleDateParts) => string;