/**
 * dateTime.ts — time-of-day helpers shared by the date controls.
 *
 * `DatePicker`, `DateRangePicker` and `DateTimeInput` all have to answer the same
 * questions once a time component enters the picture: what is this Date's "HH:mm",
 * how do I put an "HH:mm" onto a picked day, and how do I keep the result inside
 * [min, max]. Extracted so the three cannot drift apart — the same D-172 rationale
 * that put the focus-trap helpers in their own module.
 *
 * INVARIANT across all of these: seconds and milliseconds are ALWAYS zeroed. The
 * controls only ever expose HH:mm, so letting a stray second ride along would make
 * two visually identical values compare unequal on the wire. Holding that through
 * the clamp is what {@link minuteBounds} is for. (NB-DATETIME-01)
 */
/** Inclusive [min,max] clamp; either bound optional.
 *
 *  Returns the BOUND ITSELF when `d` falls outside it, so the seconds invariant
 *  above only survives if the bounds are already minute-aligned — pass them
 *  through {@link minuteBounds} first for a minute-granular control. */
export declare function clampToRange(d: Date, min?: Date, max?: Date): Date;
/** Smallest whole minute >= `d`. Already-aligned values are returned unchanged. */
export declare function minuteCeil(d: Date): Date;
/** Largest whole minute <= `d`. */
export declare function minuteFloor(d: Date): Date;
/**
 * Minute-aligned bounds for a minute-granular control: `min` rounded UP, `max`
 * rounded DOWN. Both moves are inward, so the aligned window is a subset of the
 * caller's — a value that clamps to an aligned bound is still inside the original
 * one, and it carries no stray seconds.
 *
 * Rounding OUTWARD would be the bug: clamping to a `max` of 17:00:45 emits
 * 17:00:45 while the time input shows "17:00", so two values that look identical
 * differ on the wire.
 *
 * A sub-minute window (e.g. min 17:00:10, max 17:00:50) contains no whole minute,
 * so inward alignment would invert it to 17:01 > 17:00 and clamp a value to 17:01
 * — OUTSIDE the caller's own max. The raw pair is returned unchanged instead: two
 * invariants are in tension there and "never leaves [min,max]" is the one that
 * matters, since a stray second is a cosmetic mismatch while an out-of-range
 * instant is a wrong value on the wire.
 */
export declare function minuteBounds(min?: Date, max?: Date): {
    min?: Date;
    max?: Date;
};
/** "HH:mm" for a Date, "" for null/undefined. */
export declare function toHhmm(d: Date | null | undefined): string;
/**
 * `day` with the hours/minutes parsed out of an "HH:mm" string, or `null` when
 * the string is not a valid time — callers no-op on `null`.
 *
 * The parse is STRICT (0-23 / 0-59) on purpose. A lenient `setHours` silently
 * NORMALIZES out-of-range parts instead of rejecting them, so "25:99" would land
 * on the FOLLOWING day at 02:39 — a day-shift the user never asked for, written
 * straight to the wire. Partial garbage is just as bad: "12:xx" would quietly
 * become 12:00. Refusing the value keeps the previous one, which is recoverable;
 * a silently shifted date is not.
 */
export declare function withTime(day: Date, hhmm: string): Date | null;
/**
 * `day` carrying `previous`'s HH:mm — the "changing the date must not silently
 * reset the time the user already picked" rule. No previous value means 00:00,
 * which is exactly what a time-less picker emits today.
 */
export declare function carryTime(day: Date, previous: Date | null | undefined): Date;
//# sourceMappingURL=dateTime.d.ts.map