/**
 * Possible delimiters between a date and a time value.
 */
export declare const TIME_DELIMITERS: string[];
/**
 * Configuration for a {@link parseLocalDate} call.
 */
export type ParseLocalDateConfig = {
    /**
     * If a timezone offset is not specified in the text, explicitly
     * add this offset before returning.  You probably don't want this
     * unless you have a very specific reason.
     */
    offsetMinutes?: number;
    /**
     * Allow time information to be specified.
     * @defaultValue false
     */
    time?: boolean;
    /**
     * Allowable delimiters between the date part and time part.
     * @defaultValue {@link TIME_DELIMITERS}
     */
    timeDelimiters?: string[];
    /**
     * Allow timezone information to be specified.
     * @defaultValue false
     */
    zone?: boolean;
};
/**
 * Parse an ISO-8860-like date, but do so assuming that the time is intended
 * to be local, not UTC.  But if allowed, the date could override this with
 * specific time zone info.
 * @remarks
 * Why bother with this?  Why not just use <kbd>Date.parse()</kbd>? JS
 * dates are tricky with how they are sometimes based on UTC, and sometimes
 * on local times, and that all depends on the string which is provided.
 * I, personally, find this constantly violates my Principle of Least
 * Surprise.
 */
export declare const parseLocalDate: (text: string, config?: ParseLocalDateConfig) => Date;
//# sourceMappingURL=parse-local-date.d.ts.map