@bitbaum/whenkit

Dates and times people can pick without typing: day chips, time chips, length chips, a readable date field over the native picker, and a booking request that resolves to { startsAt, endsAt } in the provider's time zone.

pnpm add @bitbaum/whenkit

import { BookingRequestPicker } from "@bitbaum/whenkit/react";
import { resolveRequest, todayIn, type BookingChoice } from "@bitbaum/whenkit";
import "@bitbaum/whenkit/styles.css";

const [choice, setChoice] = useState<BookingChoice | null>(null);

<BookingRequestPicker
  unit="hour" // "day" for things rented by the day — never asks for a time
  zone="Europe/Zurich" // the zone of the thing being booked
  hours={{ start: "09:00", end: "18:00" }}
  openWeekdays={[1, 2, 3, 4, 5]}
  lengths={[60]} // optional: one value = fixed duration, no length row
  value={choice}
  onChange={setChoice}
/>;

// On send:
const slot = resolveRequest(choice, { zone: "Europe/Zurich", today: todayIn("Europe/Zurich") });
// → { startsAt, endsAt, flexible }  (null while incomplete)

Why

The fleet had ~120 raw <input type="date|time|datetime-local"> fields in 15 repos. Booking dialogs asked for a start AND an end date-time — two fields showing the browser's locale placeholder (tt.mm.jjjj, --:--) — for a studio rented by the day. Three decisions replace that:

1. The listing decides the shape. Rented by the day → pick days, no times. Hourly → pick a day, then a start time inside opening hours, then a length. Nobody types an end time. Flexible → at most a preferred day; the provider proposes the slot.
2. Chips for the common case. The next two weeks as tappable days ("Today", "Tomorrow", "Fri 10"), plus "Another date…" for anything further out.
3. Keep the native picker, lose the ugly field. On a phone the platform picker is the best there is. DateField keeps the real <input> (keyboard, autofill, a11y) transparent on top of a display that reads "Sat, 11 Oct · 14:00", and opens the picker on tap.

Replacing the date inputs you already have

DateInput is a drop-in for <input type="date"> / type="datetime-local": same props, same onChange(event), so a call site changes its tag and nothing else.

import { DateInput } from "@bitbaum/whenkit/react";
import "@bitbaum/whenkit/styles.css";

// before: <input type="date" value={due} onChange={(e) => setDue(e.target.value)} className="input" />
<DateInput value={due} onChange={(e) => setDue(e.target.value)} className="input" />;

Your own className lands on the visible box, and it wins: whenkit's look sits in @layer base, below Tailwind utilities and plain app CSS. The real input stays on top, invisible, so the picker, keyboard entry, autofill, required validation and form submission all keep working. Controlled (value) or uncontrolled (defaultValue + name, e.g. a server-action form). The empty state and weekday/month words follow <html lang> (or pass locale / placeholder).

Migrating a repo

# one re-export per app: components/ui/date-input.tsx
#   "use client"; import "@bitbaum/whenkit/styles.css"; export { DateInput } from "@bitbaum/whenkit/react";
node node_modules/@bitbaum/whenkit/scripts/migrate-date-inputs.mjs src --import "@/components/ui/date-input"          # dry run
node node_modules/@bitbaum/whenkit/scripts/migrate-date-inputs.mjs src --import "@/components/ui/date-input" --write  # apply

It changes the tag and adds one import — nothing else — and lists what it will not guess (spread props, a dynamic type={…}). --from Input converts an app's own wrapper component instead of the raw <input>. Tested on tricky fixtures (test/codemod.test.js); a second run changes nothing.

Rules it enforces

• Dates are YYYY-MM-DD, times HH:MM — wall-clock strings. They become an instant in one place, zonedToUtc, in the provider's zone (DST gaps resolve forward). new Date("2026-10-11") drift cannot happen.
• "Today" is the provider's today (todayIn(zone)), and start times already past are not offered.
• Every chip and day is a 44px target; the date input is 16px (iOS zooms below that); the day strip scrolls inside itself, never the page.
• Chip rows are real radio groups (arrow keys, one tab stop); day buttons carry full spoken labels ("Tomorrow, Friday 9 October").
• Words come from Intl ("Morgen", "demain") — override the few sentences via words.

API

Core (@bitbaum/whenkit, no React): todayIn, nowIn, addDays, daysBetween, nextDays, weekday, zonedToUtc, isISODate, isWallTime, dayLabel, formatTime, formatLength, timeSlots, lengthOptions, DEFAULT_HOURS, isComplete, resolveRequest, describeRequest, type BookingChoice.

React (@bitbaum/whenkit/react): BookingRequestPicker, DayStrip, ChipGroup, DateInput, DateField (a DateInput with its own label).

Look (@bitbaum/whenkit/styles.css): --wk-* variables default to @bitbaum/design-tokens; set them once to match any other app.

Develop

pnpm install
pnpm run verify   # format, lint, types, build, unit + render tests, browser checks

dist/ is committed so a github: install needs no build step; CI fails if it differs from what the source builds to. The browser check (test/browser.mjs) drives Chromium at 1280px and 390px, light and dark, and taps a booking end to end.

npm

Not yet on npm — the first publish needs the account owner's passkey (see .github/workflows/publish.yml). Until then install from a tag as above.