Use a time component when a person needs to provide a time of day. Keep the time question distinct from a date question unless the service needs both values and can explain their relationship.

Ask for time only when it matters

A time can be hard to recall precisely. Collect it only when the service needs a specific time, such as the start of an appointment, an incident, a delivery window or a preferred contact time.

Write a clear label:

• What time did the incident happen?
• What time would you prefer us to call?
• What time does the event start?

Use hint text to explain the expected convention, including whether the service expects a 24-hour time or an AM/PM convention. If an approximate time is acceptable, say so and consider collecting a time range or an explanation instead of an exact value.

flowchart TD
  A[Does the service need a precise time?] --> B{Can the person know it accurately?}
  B -- Yes --> C[Use a required time component]
  B -- No --> D[Allow an optional time or collect an approximation]
  A --> E{Is the time linked to a date?}
  E -- Yes --> F[Use a separate, clearly related date component]

Make validation helpful

Set the component as required only if the service cannot continue without a time. Use a custom error message when it can clarify the correction, for example: “Enter the time using the 24-hour clock, such as 14:30.”

If a time is only required in some circumstances, use conditional validation. This checks whether the answer is valid when the page is submitted; it does not show or hide the component. For a small same-page follow-up, reveal the time component from the relevant choice instead.

Link dates and times clearly

When you collect both date and time, keep their labels parallel:

If the service operates across time zones, explain which local time zone the person should use. Do not silently assume the service operator’s time zone.

Pre-filled times and review pages

Pre-populate a time only when it comes from a reliable earlier answer or trusted source. If the person can change it, make that clear and test returning to the page and resuming a draft.

On review pages, ensure the time has a specific label and is understandable without surrounding page context. Do not display only a raw stored value where a person may need to check it.

Testing checklist

• The question makes clear what the time refers to.
• The expected time convention is stated where it could be ambiguous.
• Required and optional behaviour matches the service rule.
• Invalid, incomplete and valid times show the expected result.
• Conditional rules work for every relevant route.
• Linked date and time fields remain understandable together.
• Time-zone expectations are clear for services used across locations.
• Pre-population and review output work correctly on a resumed draft.

Related guidance

• Date components
• Shared component settings
• Use conditions and branching