# Time components

Source: https://govform.com/resources/documentation/article/23-08-component-time
Topic: Component Settings

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:

| Date | Time |
| --- | --- |
| `What date did the appointment start?` | `What time did the appointment start?` |
| `What date did the incident happen?` | `What time did the incident happen?` |

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](<https://govform.com/resources/documentation/article/23-07-component-date>)
-   [Shared component settings](<https://govform.com/resources/documentation/article/23-00-component-shared-settings>)
-   [Use conditions and branching](<https://govform.com/resources/documentation/article/07-use-conditions-and-branching>)