Time picker

Problem Context

• The user is choosing a specific time for an appointment, meeting, reminder, delivery, pickup, service window, or deadline.
• The product accepts times only in consistent increments such as 5, 15, or 30 minutes.
• The meaning of the time may depend on AM/PM, locale, timezone, store, office, or service location.
• Some time slots may be unavailable because of operating hours, capacity, holidays, or staffing.
• The backend needs a normalized 24-hour value even when the UI uses localized 12-hour display.

Selection Rules

• Choose time picker when users need a specific schedulable clock time from predictable increments.
• Use text input when the answer is approximate, historical, unknown, or naturally written in words.
• Use select or radio controls when the only valid choices are broad windows such as Morning, Afternoon, or Evening.
• Use input mask only when a strict time code is required and the interaction still supports paste, correction, and clear errors.
• Do not use a date picker or date range picker to collect time of day unless date and time are deliberately combined in one workflow.
• Use 12-hour display with an explicit AM/PM control when that is familiar to the audience.
• Use 24-hour display when the domain expects it, such as transportation, operations, healthcare, or international scheduling.
• Show timezone or location whenever the same displayed time could refer to different moments.
• Make increments match real availability, not arbitrary minute lists.
• Validate required value, time format, min time, max time, step increment, unavailable slots, AM/PM, and timezone before submission.

Required States

• Empty labelled time field with persistent hint and optional timezone default.
• Focused typed-query state that filters available time options.
• Open suggestion list with valid increments and unavailable slots distinguished.
• Selected time state synchronized with AM/PM and timezone selectors.
• Manual typed value state that preserves user edits before validation.
• Invalid format error state for values that are not parseable times.
• Off-step error state for times outside the configured increment.
• Out-of-hours error state for times before minimum or after maximum.
• Unavailable slot error state for capacity-blocked times.
• Submitted state showing canonical 24-hour time and timezone.

Interaction Contract

• Typing filters option strings without erasing the raw typed value.
• Arrow keys move through filtered options and Enter commits the highlighted option.
• Selecting an option writes the display time but does not submit the surrounding form.
• Changing AM/PM updates the canonical value without changing typed minutes.
• Changing timezone preserves local time unless the workflow explicitly converts across zones.
• Submitting validates format, hour range, minute increment, unavailable slots, AM/PM, timezone, and required state together.
• Errors identify the failing factor, such as minutes must be 00 or 30, time is outside clinic hours, or choose a timezone.

Implementation Checklist

• Define the time purpose, accepted increments, minimum time, maximum time, unavailable slots, locale display, AM/PM policy, timezone policy, and canonical storage format.
• Build a labelled input or combobox with persistent hint text, filtered suggestions, selected option, empty query state, unavailable option state, AM/PM selector, and timezone selector when required.
• Generate option labels with familiar strings such as 9:00 AM while storing canonical leading-zero 24-hour values.
• Validate typed and selected values with the same range, step, availability, timezone, and required-field rules on client and server.
• Keep user-entered values visible after validation errors and mark only the field or selector that caused the error.
• Test keyboard filtering, screen readers, browser autofill, mobile time keyboards, localization, 12-hour and 24-hour formats, timezone changes, unavailable slots, and server-returned errors.
• Avoid automatic submission or result refresh when a user highlights, filters, or selects a time.

Common Generated-UI Mistakes

• Using a minute-by-minute dropdown for a schedule that only accepts 30-minute increments.
• Storing 2:00 without AM/PM or timezone context.
• Using a rigid mask that rejects valid localized entry or paste.
• Auto-submitting when a time option is selected.
• Showing only HH:mm text to users who expect 12-hour time with AM and PM.
• Applying the same error style to every field instead of naming hour, minute, period, timezone, range, or availability failure.
• Forcing a picker for exact historic times that users need to type from a document.

Critique Questions

• Is the user scheduling a future service time, or entering a remembered or historical exact time?
• What increments are actually bookable, and how will unavailable slots be represented?
• Does the audience expect 12-hour time, 24-hour time, or both?
• Which timezone or location gives meaning to this time?
• Can users type, filter, select, correct, paste, and submit without losing their value?
• What canonical time string does the backend receive?