Skip to main content
Designsystemet logoDesignsystemet logo

What are you looking for?

Try searching for…

Patterns

Ask users for date and time

Asking users for date and time is often solved in a more complicated way than necessary. In many situations, standard input fields are both faster to use and easier to understand than custom-built date pickers.

Digdir, BrønnøysundregistreneUpdated March 5, 2026

This article has been developed by the design system team at The Norwegian Digitalisation Agency in collaboration with Brønnøysundregistrene. It has not gone through the same collaborative process as the patterns in the Pattern collaboration. We would like feedback on the article. Please share it in Slack or in this discussion thread on github.com.

How you ask users for date and time should be based on the information you actually need. Some dates are easy to remember, such as a date of birth, while others must be read from documents or cards. In some situations, an approximate date is sufficient, or a date relative to today. In other cases, users need to choose a date or time from a predefined set of options.

Avoid making the task more complicated than necessary. Custom-built date pickers often result in lower accessibility and more friction than simple text fields. They can be difficult to use with a keyboard, provide poor support for screen readers, and require unnecessary navigation when the user already knows the date.

Known dates

When asking for well-known dates, such as a date of birth or wedding date, simple text inputs work well. Users already know the answer and often prefer to type it directly, rather than navigating through a calendar.

Consider splitting the date into separate fields for day, month and year. This makes it easier to enter the date correctly and provides better support for assistive technologies. When asking users to enter a date exactly as it appears on a bank card, passport or other document, the fields should match the format shown in that document. This makes it easier to transfer the date accurately and reduces the risk of errors.

In the example above, we use inputmode="numeric" to provide a numeric keyboard on mobile phones and tablets. We deliberately avoid using type="number" for day, month and year fields. type="number" is designed for numeric values that can be incremented or decremented, and introduces functionality such as spin buttons and automatic validation that is not always appropriate for dates. It can also create accessibility issues (mozilla.org), including problems for screen reader users and unintended value changes.

Date from a predefined set of options

If you know that users need to choose a date or time from a limited set of options, for example available appointments in the coming week, it may be more efficient to present these as ready-made choices.

When the number of options is very limited, such as a few dates or times, Radio can be a good choice. It allows users to quickly select an option without having to type anything.

Let users narrow down the options

When the number of options increases, a Select can be useful to narrow down the list. Users can choose preferred weeks, days or time ranges, and then see the available options based on that selection.

Note: The example below is not connected to an actual data source. It illustrates how users can narrow down the options before seeing the available appointments.

You should only show options that have available appointments, and avoid disabling weeks without availability, as this may create confusion. Explain in advance that only weeks with available times are shown, so users understand why some weeks are not available to select.

Specific date in the near future or past

In some cases, when users need to choose a specific date close to today, visual support can be helpful. An Input with type="date" allows users to either enter the date directly or use the browser's built-in date picker. This often provides a good balance between flexibility and support.

Support varies between browsers and devices in terms of functionality, appearance and interaction, but the solution is often more accessible and robust than custom-built alternatives.

Be aware that type="date" is controlled by the user's operating system and regional settings, not by the language of the website. This can result in the date being displayed in a format the user does not expect. Consider whether additional clarity is needed, for example by displaying the selected date in plain text with the month written out in words, or by otherwise asking the user to confirm the date before it is saved.

Start and end date

When users need to provide a period, the start date and end date should be clearly shown together. Use two separate fields and make it clear which date is which.

Place the fields in a logical order and validate that the end date is not earlier than the start date. If the dates depend on each other, error messages should explain what is wrong and how the user can correct it.

Time - start and end

When users need to provide a time interval, such as opening hours or the duration of a meeting, an Input with type="time" can be used. It allows users to enter the time directly, while the browser provides additional support.

Use separate fields for start and end time, and display them clearly together.

Approximate date

If users only need to provide month and year, they should be able to do exactly that. This is particularly relevant when the event took place a long time ago and users may not know the exact date.

For example, you can allow users to enter an approximate date in a free text field, or provide separate fields for month and year only, as shown in the example below.

Date relative to another date

In some situations, it is more natural to ask for dates relative to another date, for example when setting up a reminder. In these cases, it may be better to use a Select to offer options such as “tomorrow”, “in 3 days” or “1 day before”. If the day of the week is important for the task, it should also be clearly displayed.

Summary

Start with the need and choose the solution that allows users to complete the task as quickly as possible. Standard text fields are often more accessible and faster to use than advanced date pickers.

  • Show ready-made options when the alternatives are limited
  • Let users type when the answer is known
  • Only ask for as precise a date and time as the situation requires
  • Use built-in browser support rather than custom-built solutions

Sources and relevant information

Designsystemet logo

Contributors

Marianne Røsvik (Digdir)Ole Martin Tangen Vad (Brønnøysundregistrene)Roy Halvor Frimanslund (Brønnøysundregistrene)Lasse Febakke Straum (Digdir)Frank Dahle (Digdir)Tobias Barsnes (Digdir)Oddbjørn Øvernes (Digdir)Michael Marszalek (Digdir)Gørild Døhl (Digdir)

Edit this page on github.com (opens in a new tab)