When to use
- Filtering views: Filtering data or reports by a time window.
- To ensure proper formatting: Avoids input errors by enforcing a standard format.
- Comparison: When comparing activity across a defined time period.
When not to use
- For relative time queries: While a Time picker may be helpful, consider adding shortcuts to the picker for a quicker selection, such as “2 hours ago”, “20 minutes ago” and “in 3 days”.
- When entering fixed or recurring time values: Consider allowing for cron expressions or pre-set time stamps users can choose from.
- When exact timing and format is not important: When users leave comments or descriptions where they reference a date or time but the formatting does not matter, provide a simple Input or Textarea.
Dos and don’ts
- Do match the time format (12hr/24hr) to the user’s locale or application setting — don’t hardcode one.
- Do include AM/PM selection clearly when using 12-hour format; ambiguity here causes real errors.
- Don’t include seconds unless the context requires it (log timestamps, precise scheduling) — it adds complexity most users don’t need.
Behavior
- Opening the control reveals a time picker calendar UI anchored to the field.
- Keyboard users must be able to type valid values and open the picker without relying on the mouse alone (implementation-specific shortcuts allowed).
- If the time value has constraints (e.g. only future times, business hours only), disable invalid times rather than letting users select them and fail on submit.
Often used with
Accessibility
- Provide distinct accessible labels for individual hour, minute, and period controls (e.g.,
aria-label="Hours",aria-label="Minutes",aria-label="AM or PM"). - Specify 12-hour or 24-hour format expectations clearly in the visual field label or through
aria-describedby. - Ensure custom increment and decrement step buttons possess explicit
aria-labeldescriptions (e.g.,aria-label="Increase hours").