@eifi1/ui-kit 0.53.0 → 0.55.0

package/src/lib/countries.ts

@@ -1,91 +0,0 @@
-/**
- * Countries as ISO 3166-1 alpha-2 codes, named by the runtime — for {@link CountrySelect}
- * and for an app that shows the code it stored ("CH") as a name somewhere else (a
- * table cell, an address line).
- *
- * The kit ships CODES, not names. Every runtime the kit supports has
- * `Intl.DisplayNames({ type: "region" })`, which names all of these in every locale
- * the browser knows — so a table of 249 names per language would be a large file
- * that is out of date the day a country is renamed (Türkiye, Czechia, Eswatini) and
- * still covers fewer languages than the browser does. What is left to ship is the
- * list of which codes ARE countries, and that is one string.
- */
-
-/**
- * Every officially assigned ISO 3166-1 alpha-2 code — the 249 countries, territories
- * and areas of the standard, upper-case, in code order.
- *
- * User-assigned codes are deliberately not in it: `XK` (Kosovo) is a widespread
- * convention, not ISO, and whether to offer it is the app's decision. An app that
- * wants it passes its own list to `CountrySelect`'s `countries` — the runtime names
- * `XK` as well.
- */
-export const COUNTRY_CODES: readonly string[] = Object.freeze(
-  (
-    "AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ " +
-    "BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM " +
-    "DO DZ EC EE EG EH ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS " +
-    "GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN " +
-    "KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ " +
-    "MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM " +
-    "PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV " +
-    "SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI " +
-    "VN VU WF WS YE YT ZA ZM ZW"
-  ).split(" "),
-);
-
-/** Two ASCII letters — the shape of an alpha-2 code, whatever the case. */
-const ALPHA_2 = /^[A-Za-z]{2}$/;
-
-/** `code` upper-cased when it has the shape of an alpha-2 code, else `undefined`. Does
- *  not check that ISO assigned it — see {@link COUNTRY_CODES} for why `XK` must pass. */
-export function normalizeCountryCode(code: string | null | undefined): string | undefined {
-  return code && ALPHA_2.test(code) ? code.toUpperCase() : undefined;
-}
-
-// One `DisplayNames` per locale, built on first use. `null` records a locale the
-// runtime refused (a malformed tag) or a runtime without the API, so neither is
-// retried for every row of a 249-row list.
-const namers = new Map<string, Intl.DisplayNames | null>();
-
-function namer(locale: string): Intl.DisplayNames | null {
-  let n = namers.get(locale);
-  if (n === undefined) {
-    try {
-      n = new Intl.DisplayNames([locale], { type: "region", fallback: "code" });
-    } catch {
-      n = null;
-    }
-    namers.set(locale, n);
-  }
-  return n;
-}
-
-/**
- * The name of the country `code` stands for, in `locale` — `countryName("CH", "de-CH")`
- * is "Schweiz". Falls back to the upper-cased code itself when the runtime has no name
- * for it, rejects the locale, or has no `Intl.DisplayNames`: a code is still the right
- * answer, where an empty cell would not be.
- *
- * `locale` defaults to English rather than to the runtime's language, the rule the
- * kit's currency names follow (`currencyName`): an app that never set a locale reads
- * the kit's English everywhere else, and a country list in the browser's language
- * beside English labels — or in the test runner's — is two languages on one form.
- *
- * The code is upper-cased first. `DisplayNames` is case-sensitive about it in some
- * runtimes (Node answers "ch" with "ch"), and the codes reach this from forms,
- * URLs and databases in either case.
- */
-export function countryName(code: string, locale: string = "en"): string {
-  const upper = code.toUpperCase();
-  const n = namer(locale);
-  if (n) {
-    try {
-      const name = n.of(upper);
-      if (name) return name;
-    } catch {
-      // Not a well-formed region subtag ("C1", "") — the code is all there is.
-    }
-  }
-  return upper;
-}

package/src/lib/data-attributes.ts

@@ -1,14 +0,0 @@
-/**
- * A component's `data-*` props, for its root element (0.50, keksdose): `data-tour`,
- * `data-testid` and the like reach the DOM even when the props are not spread there
- * whole. TypeScript does not check hyphenated JSX attributes, so without this a
- * `data-tour` on such a component vanished without an error.
- */
-export type DataAttributes = { [attribute: `data-${string}`]: string | number | boolean | undefined };
-
-/** Only the `data-*` entries of `props`. */
-export function dataAttributes(props: object): DataAttributes {
-  const out: DataAttributes = {};
-  for (const [k, v] of Object.entries(props)) if (k.startsWith("data-")) out[k as `data-${string}`] = v;
-  return out;
-}

package/src/lib/date-format.ts

@@ -1,227 +0,0 @@
-import { formatLocaleOf } from "../i18n/languages";
-import type { KitDateFormatter } from "../i18n/kit-labels";
-import { pad, toLocalIso } from "./dates";
-import { dateFormatter } from "./intl-cache";
-import { isBareIsoDay } from "./iso-day";
-
-/**
- * The date-format preference (0.46, lifted from keksdose's `date-format-store.ts`,
- * feedback #180): how a DAY is written — the order of day, month and year and the
- * separator between them — as a choice of its own, apart from the interface language.
- * "Read the app in English and still see German dates", or ISO everywhere.
- *
- * keksdose's rules, which the kit keeps:
- *
- * 1. **A label that identifies a day follows the preference** — anything that prints
- *    day, month and year goes through {@link formatDateWithPreference} (or the
- *    provider's `formatDate`, {@link dateFormatterFor}, for the kit's own date fields).
- * 2. **A label without a day follows the language**: "August 2026", a month or weekday
- *    NAME has no order to arrange. {@link dateFormatterFor} answers `""` for a month or a
- *    year, so the kit keeps its own rendering in the language.
- * 3. **A clock time follows the language**: `sv-SE` is a statement about digit order in
- *    a date, not about a 12- or 24-hour clock.
- * 4. **A weekday's NAME follows the language** (dev#546): `sv-SE` means "year first,
- *    with dashes", not "the reader speaks Swedish" — so with `weekday` the day's name is
- *    the language's, joined to the date the preference renders.
- *
- * The preference is the APP's to keep — keksdose holds it per device (a persisted store,
- * not an account column: nothing server-written formats a date for the reader). The kit
- * owns the vocabulary, the resolver, the renderer and the settings field
- * ({@link DateFormatSetting}).
- */
-
-/** `"auto"` follows the interface language (the default — nobody's dates move until
- *  they ask); the rest are BCP 47 tags chosen for the SHAPE they produce: German
- *  01.08.2026, British 01/08/2026, US 08/01/2026, ISO 2026-08-01. */
-export type DateFormatPreference = "auto" | "de-DE" | "en-GB" | "en-US" | "sv-SE";
-
-/** The options in the order the setting lists them: `auto` first (the default), then
- *  German → UK → US → ISO. */
-export const DATE_FORMAT_PREFERENCES: readonly DateFormatPreference[] = ["auto", "de-DE", "en-GB", "en-US", "sv-SE"];
-
-/** Whether `value` is one of {@link DATE_FORMAT_PREFERENCES} — for a value read back from
- *  storage, where anything else falls back to `"auto"`. */
-export function isDateFormatPreference(value: unknown): value is DateFormatPreference {
-  return typeof value === "string" && (DATE_FORMAT_PREFERENCES as readonly string[]).includes(value);
-}
-
-/** A resolved preference: the locale and `Intl` options the date itself is rendered
- *  with, and — only when asked for — the locale the weekday's NAME comes from. */
-export interface ResolvedDateFormat {
-  locale: string | undefined;
-  options: Intl.DateTimeFormatOptions;
-  /** The language's format locale, present when `weekday` was asked for. */
-  weekday?: { locale: string | undefined };
-}
-
-/** What {@link resolveDateFormat} and the renderers take beyond the preference. */
-export interface DateFormatOptions {
-  /** Name the day of the week too, in the interface language ("Mo., 01.08.2026"). A date
-   *  in a COLUMN carries it; a date in a SENTENCE does not (keksdose dev#546). */
-  weekday?: boolean;
-  /**
-   * 0.52: the IANA zone a TIMESTAMP's day and clock are read in ("Europe/Zurich") — pass
-   * the `<UiKitProvider timeZone>` (`useKitTimeZone()`), so an app's own column says what
-   * the kit's components say for the same instant. Left out: the device's. A bare
-   * "YYYY-MM-DD" ignores it: a calendar day is the day it names in every zone. A zone
-   * `Intl` refuses reads as the device's. The renderers read it; {@link resolveDateFormat}
-   * does not.
-   */
-  timeZone?: string;
-}
-
-/**
- * What a date is rendered with, given the preference and the interface language
- * (`language`: a code or tag — `"de"`, `"en"`, i18next's `resolvedLanguage`; it is read
- * through `formatLocaleOf`, so English is British and an unshipped tag stays itself).
- *
- * `"auto"` keeps the short-month shape ("01 Aug 2026", "01. Aug. 2026"); every explicit
- * choice is all-numeric, the only way it produces the shape its option promises —
- * `month: "short"` under `sv-SE` would print "2026 aug. 01", not ISO.
- */
-export function resolveDateFormat(
-  preference: DateFormatPreference,
-  language: string | undefined,
-  options: DateFormatOptions = {},
-): ResolvedDateFormat {
-  const languageLocale = language ? formatLocaleOf(language) : undefined;
-  const weekday = options.weekday ? { weekday: { locale: languageLocale } } : {};
-  if (preference === "auto") {
-    return { locale: languageLocale, options: { year: "numeric", month: "short", day: "2-digit" }, ...weekday };
-  }
-  return { locale: preference, options: { year: "numeric", month: "2-digit", day: "2-digit" }, ...weekday };
-}
-
-/**
- * `dateText`, already rendered under the preference, with the day's NAME around it in
- * `locale` (the language's). Not "weekday alone + comma": German says "So" alone and
- * "So., 06.09.2026" in company. The full date is formatted in the language and split
- * into parts; what that language puts before the first and after the last day/month/
- * year part (the weekday, its comma) frames the preference's digits — so where the two
- * locales coincide the output is the native string, character for character.
- */
-function withWeekday(date: Date, dateText: string, locale: string | undefined, options: Intl.DateTimeFormatOptions) {
-  const isDatePart = (p: Intl.DateTimeFormatPart) => p.type === "day" || p.type === "month" || p.type === "year";
-  const parts = dateFormatter(locale, { weekday: "short", ...options }).formatToParts(date);
-  const first = parts.findIndex(isDatePart);
-  if (first === -1) return dateText;
-  let last = first;
-  parts.forEach((p, i) => {
-    if (isDatePart(p)) last = i;
-  });
-  const join = (ps: Intl.DateTimeFormatPart[]) => ps.map((p) => p.value).join("");
-  return join(parts.slice(0, first)) + dateText + join(parts.slice(last + 1));
-}
-
-/**
- * A date under the preference: `""` for no value, the input itself when it does not
- * parse. A bare "YYYY-MM-DD" is the calendar day it names in every zone (formatted in
- * UTC, undoing `new Date`'s UTC-midnight parse — west of Greenwich it read a day early);
- * a timestamp is an instant, read in `options.timeZone`, else the reader's zone. The
- * weekday, when asked for, is rendered in the same zone, so a Sunday is never captioned
- * Saturday.
- */
-export function formatDateWithPreference(
-  value: string | Date | null | undefined,
-  preference: DateFormatPreference,
-  language: string | undefined,
-  options: DateFormatOptions = {},
-): string {
-  if (!value) return "";
-  const resolved = resolveDateFormat(preference, language, options);
-  const dateOnly = isBareIsoDay(value);
-  const date = typeof value === "string" ? new Date(value) : value;
-  if (Number.isNaN(date.getTime())) return String(value);
-  const render = (timeZone: string | undefined) => {
-    const intl: Intl.DateTimeFormatOptions = timeZone ? { ...resolved.options, timeZone } : resolved.options;
-    // Through the shared cache (refactor audit 2026-10-30, DUP-2): a `toLocaleDateString`
-    // builds a formatter per call, which is why keksdose kept its own copy of this
-    // renderer — 392 ms per click on a 270-row register (dev#632).
-    const text = dateFormatter(resolved.locale, intl).format(date);
-    return resolved.weekday ? withWeekday(date, text, resolved.weekday.locale, intl) : text;
-  };
-  if (dateOnly) return firstAccepted([() => render("UTC")], () => value);
-  // A zone `Intl` refuses: the reader's own day, as `clockTime` reads the reader's own
-  // clock — never the UTC day `toISOString` gave, a day off around midnight (0.52 code
-  // review, this file).
-  return firstAccepted([() => render(options.timeZone), () => render(undefined)], () => toLocalIso(date));
-}
-
-/** The first of `renders` that `Intl` accepts — a language tag or a zone it refuses
- *  throws — else `last()`: the ISO day or the clock rather than nothing (keksdose's
- *  fallback). */
-function firstAccepted(renders: readonly (() => string)[], last: () => string): string {
-  for (const render of renders) {
-    try {
-      return render();
-    } catch {
-      // Refused: the next.
-    }
-  }
-  return last();
-}
-
-/**
- * The clock time of `date` as the language writes it ("14:05"), two digits each: rule 3,
- * a clock follows the language, never the preference — `sv-SE` is a statement about the
- * order of a date's digits, not about a 12- or 24-hour clock. `language` is read through
- * `formatLocaleOf`, so English is the British 24-hour clock, not "02:05 PM" in a
- * German household's app. In `timeZone` when given, else the reader's.
- *
- * @internal Shared with the kit's own day formatter; not part of the barrel.
- */
-export function clockTime(date: Date, language: string | undefined, timeZone?: string): string {
-  const locale = language ? formatLocaleOf(language) : undefined;
-  const clock = (zone: string | undefined) =>
-    dateFormatter(locale, { hour: "2-digit", minute: "2-digit", ...(zone ? { timeZone: zone } : null) }).format(date);
-  // A zone `Intl` refuses: the reader's own clock, as `isoDayIn` reads the reader's own
-  // day — the UTC clock `toISOString` gave printed 13:05 for 14:05 in Zurich, an hour or
-  // more off with no error (0.52 code review, this file).
-  const reader = () => `${pad(date.getHours())}:${pad(date.getMinutes())}`;
-  return firstAccepted([() => clock(timeZone), () => clock(undefined)], reader);
-}
-
-/**
- * A timestamp under the preference (0.52, keksdose's `formatDateTimeFor`, refactor audit
- * 2026-10-30, DUP-2): the date as {@link formatDateWithPreference} writes it, weekday
- * when asked for, then the clock time in the LANGUAGE ({@link clockTime}): "01.08.2026,
- * 14:05", "Sa., 01.08.2026, 14:05". keksdose's notification inbox and admin scheduler
- * were where an explicit ISO choice did nothing until it wrote this. `""` for no value,
- * the input itself when it does not parse; a bare "YYYY-MM-DD" names no moment, so it
- * prints as the date alone.
- *
- * Day and clock in `options.timeZone` — pass the provider's (`useKitTimeZone()`): without
- * it they were the device's, and an app on Zurich time read from New York printed 09:05
- * in its own column where the kit's inbox printed 14:05 for the same instant (0.52 code
- * review, this file).
- */
-export function formatDateTimeWithPreference(
-  value: string | Date | null | undefined,
-  preference: DateFormatPreference,
-  language: string | undefined,
-  options: DateFormatOptions = {},
-): string {
-  if (!value) return "";
-  if (isBareIsoDay(value)) return formatDateWithPreference(value, preference, language, options);
-  const date = typeof value === "string" ? new Date(value) : value;
-  if (Number.isNaN(date.getTime())) return String(value);
-  return `${formatDateWithPreference(date, preference, language, options)}, ${clockTime(date, language, options.timeZone)}`;
-}
-
-/** The sample an option is labelled with — 1 August 2026 in its shape, the shape being
- *  the whole choice (a country name would say nothing about the digit order). */
-export function dateFormatSample(preference: DateFormatPreference, language: string | undefined): string {
-  return formatDateWithPreference("2026-08-01", preference, language);
-}
-
-/**
- * The `<UiKitProvider formatDate>` for a preference — so the kit's own date fields
- * (DatePicker, DateRangePicker, DateMark) write a day as the app's dates do. A day
- * follows the preference, with the weekday where the kit suggests it; a month or a year
- * answers `""` and keeps the kit's rendering in the language (rule 2). Rebuild it when
- * the preference or the language changes (a `useMemo` on both).
- */
-export function dateFormatterFor(preference: DateFormatPreference, language: string | undefined): KitDateFormatter {
-  return (iso, { unit, weekday, locale }) =>
-    unit === "day" ? formatDateWithPreference(iso, preference, locale ?? language, { weekday }) : "";
-}

package/src/lib/dates.ts

@@ -1,266 +0,0 @@
-/**
- * ISO date helpers, collected from copies that were scattered across the pages.
- *
- * **Every "what day is it" helper here reads the LOCAL calendar** — one family, not
- * two. It used to be two: these all built a local Date and then read it back through
- * `toISOString()`, which is UTC, so east of Greenwich they all returned YESTERDAY
- * between local midnight and the UTC rollover. The old module note called that
- * deliberate and warned against changing it. It was not defensible, and dev#471 is
- * what it cost:
- *
- * > *"Just entered a tx now from scheduled. But it still shows as upcoming. Is there
- * > a problem with timezones? It is currently 1 o clock middle european summer time."*
- *
- * There was: at 01:00 CEST `todayIso()` answered with the 14th, the row the scheduler
- * had just booked was dated the 15th, and `isUpcoming` compares the two strings — so a
- * transaction entered a second ago read as one still to come. The same slip moved
- * `startOfMonthIso()` onto the last day of the PREVIOUS month for an hour every first
- * of the month, which is a report range nobody would have questioned.
- *
- * A calendar day only means anything to the human reading it, and every caller here —
- * the register's today, the date-range presets, the budget cursor, a new
- * transaction's default date — is asking that question. There is no caller for whom
- * "the UTC day" is the right answer; the server compares plain dates with no zone at
- * all, so sending it the user's local day is also what it wants.
- */
-
-/** Zero-pad a number to two digits ("3" -> "03"). */
-export function pad(n: number): string {
-  return String(n).padStart(2, "0");
-}
-
-/** Today as "YYYY-MM-DD" on the LOCAL calendar (see the module note). */
-export function todayIso(): string {
-  return toLocalIso(new Date());
-}
-
-/** A Date as a local-time "YYYY-MM-DD" string. */
-export function toLocalIso(d: Date): string {
-  return `${d.getFullYear()}-${pad(d.getMonth() + 1)}-${pad(d.getDate())}`;
-}
-
-/** A Date as a local-time "YYYY-MM" month key. */
-export function monthKey(d: Date): string {
-  return `${d.getFullYear()}-${pad(d.getMonth() + 1)}`;
-}
-
-// ---------- Date-range presets + calendar helpers ----------
-// Local-calendar like todayIso (see the module note); used by the data-table date
-// filter and its MiniCalendar. Each one mutates a local Date and must therefore READ
-// it back locally — going out through toISOString() is what shifted every one of
-// these by a day near midnight (dev#471).
-
-/** Today shifted by `days`, as "YYYY-MM-DD". */
-export function shiftIso(days: number): string {
-  const d = new Date();
-  d.setDate(d.getDate() + days);
-  return toLocalIso(d);
-}
-
-/** First day (Monday) of the current week, as "YYYY-MM-DD". */
-export function startOfWeekIso(): string {
-  const d = new Date();
-  const day = d.getDay();
-  const diff = (day + 6) % 7; // monday = 0
-  d.setDate(d.getDate() - diff);
-  return toLocalIso(d);
-}
-
-/** First day of the month `offsetMonths` from now, as "YYYY-MM-DD". */
-export function startOfMonthIso(offsetMonths = 0): string {
-  const d = new Date();
-  d.setDate(1);
-  d.setMonth(d.getMonth() + offsetMonths);
-  return toLocalIso(d);
-}
-
-/** Last day of the month `offsetMonths` from now, as "YYYY-MM-DD". */
-export function endOfMonthIso(offsetMonths = 0): string {
-  const d = new Date();
-  d.setDate(1);
-  d.setMonth(d.getMonth() + offsetMonths + 1);
-  d.setDate(0);
-  return toLocalIso(d);
-}
-
-/** First day of the year `offsetYears` from now, as "YYYY-MM-DD". */
-export function startOfYearIso(offsetYears = 0): string {
-  const d = new Date();
-  d.setMonth(0);
-  d.setDate(1);
-  d.setFullYear(d.getFullYear() + offsetYears);
-  return toLocalIso(d);
-}
-
-/** Last day of the year `offsetYears` from now, as "YYYY-MM-DD". */
-export function endOfYearIso(offsetYears = 0): string {
-  const d = new Date();
-  d.setMonth(11);
-  d.setDate(31);
-  d.setFullYear(d.getFullYear() + offsetYears);
-  return toLocalIso(d);
-}
-
-/** Parse a "YYYY-MM-DD" string to a local-midnight Date, or null if malformed —
- *  where "malformed" includes a date that does not exist.
- *
- *  The falsy check alone was not enough. `new Date(y, m - 1, d)` ROLLS OVER out-of-range
- *  components rather than refusing them, so "2026-13-45" came back as 2027-02-14 and
- *  "2026-02-30" as 2026-03-02: a valid-looking Date for a day that never happened. No
- *  caller could tell — {@link formatIsoDate} blanks only on `null`, so the invented
- *  date formatted and displayed exactly like a real one.
- *
- *  The round-trip is the check: build the Date, then read the components back off it.
- *  A value that rolled over cannot answer with the numbers it was given. That is the
- *  same shape {@link sameYmd} already expresses, applied to a Date and its source. */
-export function parseIsoDate(s: string): Date | null {
-  if (!s) return null;
-  const [y, m, d] = s.split("-").map(Number);
-  if (!y || !m || !d) return null;
-  if (!Number.isInteger(y) || !Number.isInteger(m) || !Number.isInteger(d)) return null;
-  const dt = new Date(y, m - 1, d);
-  if (Number.isNaN(dt.getTime())) return null;
-  if (dt.getFullYear() !== y || dt.getMonth() !== m - 1 || dt.getDate() !== d) return null;
-  return dt;
-}
-
-/** Format a "YYYY-MM-DD" string for display in `locale` (empty string when
- *  unparseable). Defaults to the locale's short numeric date; pass `options` to
- *  override (e.g. `{ dateStyle: "medium" }`). `locale` may be `undefined` since 0.34 —
- *  the runtime's default, as `Intl` reads it and as every other kit formatter takes it
- *  (DUP-11: DatePicker re-wrapped this function only to pass none). */
-export function formatIsoDate(iso: string, locale: string | undefined, options?: Intl.DateTimeFormatOptions): string {
-  const d = parseIsoDate(iso);
-  return d ? d.toLocaleDateString(locale, options) : "";
-}
-
-/** A "YYYY-MM-DD" string shifted by `days` (negative shifts back), or the input
- *  unchanged when it isn't a parseable date.
- *
- *  Local-time throughout — {@link parseIsoDate} builds a local-midnight Date and
- *  {@link toLocalIso} reads local components back, so this never slides a day the way
- *  a `toISOString()` round-trip does west of UTC. */
-export function addDaysIso(iso: string, days: number): string {
-  const d = parseIsoDate(iso);
-  if (!d) return iso;
-  d.setDate(d.getDate() + days);
-  return toLocalIso(d);
-}
-
-/**
- * `d` moved by whole months, keeping the day of the month where the target has one.
- * `setMonth` alone ROLLS OVER — 31 January + 1 month is 3 March — which would skip
- * February entirely for anyone paging through the year with PageDown. Returns a new
- * Date; `d` is not touched.
- */
-export function addMonthsClamped(d: Date, months: number): Date {
-  const day = d.getDate();
-  const out = new Date(d.getFullYear(), d.getMonth() + months, 1);
-  const lastOfTarget = new Date(out.getFullYear(), out.getMonth() + 1, 0).getDate();
-  out.setDate(Math.min(day, lastOfTarget));
-  return out;
-}
-
-/**
- * The first day of the week in `locale`, as a `Date#getDay` index (0 = Sunday).
- *
- * `Intl.Locale#getWeekInfo()` is the standard spelling; V8 shipped it first as the
- * `weekInfo` accessor, and Firefox has neither yet — hence both reads and a Monday
- * fallback, which is ISO 8601. Its `firstDay` counts 1 = Monday … 7 = Sunday, so `% 7`
- * maps it onto `getDay`. `undefined` asks for the runtime's default locale.
- */
-export function localeWeekStart(locale: string | undefined): 0 | 1 | 2 | 3 | 4 | 5 | 6 {
-  try {
-    const tag = locale ?? new Intl.DateTimeFormat().resolvedOptions().locale;
-    const loc = new Intl.Locale(tag) as Intl.Locale & {
-      getWeekInfo?: () => { firstDay: number };
-      weekInfo?: { firstDay: number };
-    };
-    const firstDay = (loc.getWeekInfo?.() ?? loc.weekInfo)?.firstDay;
-    if (typeof firstDay === "number") return (firstDay % 7) as 0 | 1 | 2 | 3 | 4 | 5 | 6;
-  } catch {
-    // A malformed tag throws from `Intl.Locale`; a calendar still has to render.
-  }
-  return 1;
-}
-
-/** Whether two Dates fall on the same local calendar day. */
-export function sameYmd(a: Date, b: Date): boolean {
-  return a.getFullYear() === b.getFullYear() && a.getMonth() === b.getMonth() && a.getDate() === b.getDate();
-}
-
-export interface DateRangePreset {
-  key: string;
-  from: string;
-  to: string;
-}
-
-/**
- * The named ranges offered by the data-table date filter (local-calendar, like
- * {@link todayIso} — see the module note). `key` maps to the consumer's
- * `table.preset_*` labels.
- */
-export function dateRangePresets(): DateRangePreset[] {
-  const mondayOffset = (new Date().getDay() + 6) % 7; // monday = 0
-  return [
-    { key: "today", from: todayIso(), to: todayIso() },
-    { key: "yesterday", from: shiftIso(-1), to: shiftIso(-1) },
-    { key: "this_week", from: startOfWeekIso(), to: todayIso() },
-    { key: "last_week", from: shiftIso(-7 - mondayOffset), to: shiftIso(-1 - mondayOffset) },
-    { key: "last_7_days", from: shiftIso(-6), to: todayIso() },
-    { key: "last_30_days", from: shiftIso(-29), to: todayIso() },
-    { key: "this_month", from: startOfMonthIso(0), to: todayIso() },
-    { key: "last_month", from: startOfMonthIso(-1), to: endOfMonthIso(-1) },
-    { key: "last_3_months", from: shiftIso(-90), to: todayIso() },
-    { key: "ytd", from: startOfYearIso(0), to: todayIso() },
-    { key: "last_year", from: startOfYearIso(-1), to: endOfYearIso(-1) },
-  ];
-}
-
-/** The last `n` WHOLE calendar months before the current one, as an inclusive
- *  `{ from, to }` — on 15 May, `n = 3` is 1 February … 30 April. Local-calendar, like
- *  everything here; `now` is for tests and for a host with its own clock. */
-export function lastFullMonthsRange(n: number, now: Date = new Date()): { from: string; to: string } {
-  const from = new Date(now.getFullYear(), now.getMonth() - n, 1);
-  // Day 0 of the current month is the last day of the previous one.
-  const to = new Date(now.getFullYear(), now.getMonth(), 0);
-  return { from: toLocalIso(from), to: toLocalIso(to) };
-}
-
-/** The last `n` WHOLE calendar years before the current one — in 2026, `n = 2` is
- *  1 January 2024 … 31 December 2025. */
-export function lastFullYearsRange(n: number, now: Date = new Date()): { from: string; to: string } {
-  const year = now.getFullYear();
-  return { from: `${year - n}-01-01`, to: `${year - 1}-12-31` };
-}
-
-export interface CalendarMonthPresetOptions {
-  /** How many whole months each month preset spans. Default `[3, 6]`. */
-  months?: readonly number[];
-  /** How many whole years each year preset spans. Default `[2]`. */
-  years?: readonly number[];
-  /** The day to count back from. Default: now, on the local calendar. */
-  now?: Date;
-}
-
-/**
- * Month-ALIGNED presets, beside the rolling-day ones of {@link dateRangePresets}.
- *
- * kastlan's accounting reports are closed by the month: "the last three months" there
- * means February, March and April, never "the 90 days up to this morning", which
- * starts mid-month and ends with a day that is still being booked. `last_3_months`
- * above is the rolling kind and stays that way for the data table's filter, so these
- * are separate keys rather than a changed meaning under an old one.
- *
- * Keys are `last_<n>_full_months` and `last_<n>_full_years`; the host labels them (the
- * same arrangement as `dateRangePresets`' keys and its `table.preset_*` strings). With
- * `DateRangePicker`, pass the key as the preset's `id` so the choice keeps its
- * identity while the dates are recomputed on every render.
- */
-export function calendarMonthPresets(options: CalendarMonthPresetOptions = {}): DateRangePreset[] {
-  const { months = [3, 6], years = [2], now = new Date() } = options;
-  return [
-    ...months.map((n) => ({ key: `last_${n}_full_months`, ...lastFullMonthsRange(n, now) })),
-    ...years.map((n) => ({ key: `last_${n}_full_years`, ...lastFullYearsRange(n, now) })),
-  ];
-}