Shared Date and Time Controls

Import DatePicker, TimePicker, DateTimePicker, Select, and Checkbox from @kulcare/ui-kit. Do not create browser-native pickers or a second select style in an app when these controls meet the field contract.

Values And OwnershipCopy Anchor Link

• DatePicker accepts a calendar Date and returns Date | undefined. Each trigger has a unique ID, or uses the caller's id. The trigger is a non-submit button. Selecting a day closes the calendar.
• TimePicker accepts and returns a local HH:MM string. Staff can type any valid minute or use the shared hour/minute selects. allowEndOfDay adds 24:00 for closing times only; 24:01 is invalid. A 24-hour selection sets minutes to 00.
• DateTimePicker accepts and returns YYYY-MM-DDTHH:MM wall-clock strings. It does not convert them to UTC or choose a facility timezone. The caller owns conversion, DST validation, and the offset-bearing API format.
• An incomplete date/time remains a draft. Required fields block form submission until both parts are valid. Selecting a date does not silently supply midnight.
• Set disabled on the shared control, not only its surrounding fieldset. This also disables actions in portalled popovers. Give each control an explicit label.

import { DateTimePicker, TimePicker } from "@kulcare/ui-kit"

<DateTimePicker
  aria-label="Maintenance start"
  value={localStart}
  onChange={setLocalStart}
  required
/>

<TimePicker
  aria-label="Closing time"
  value={closingTime}
  onChange={setClosingTime}
  allowEndOfDay
  required
/>

Hospital UseCopy Anchor Link

Hospital Settings uses these shared controls for weekly hours and dated maintenance. The OT booking editor uses the same calendar, clock, and select controls. Partial or invalid start times stay in the draft and disable Save. The app converts complete local values with its facility-time helper and preserves nonexistent local times as invalid drafts. The API still validates rules under the scheduling lock. Shared controls do not grant access or establish clinical clearance.

Hospital's local type facade refers to the generated UI-kit declarations for these exports. Build the UI kit before a standalone Hospital typecheck. Canonical frontend CI prepares workspace packages. Component interaction tests live in the Hospital suite, which has the rendering dependencies, rather than adding new test dependencies to the UI-kit package.