I am working on an payroll application in which date input fields are used in different types of user scenarios (for example, entering your date of birth, but also entering the start/end date of a contract, the start date of a change in wage, ...);

We use 1 input field with the format DD/MM/YYYY, allowing formats such as DDMMYYYY, DD-MM-YYYY, DDMMYY, etc., combined with a date picker. The above formats all support cases in which the user enters 6 digits, but my question is on the use case in which a user would enter only 4 digits, for example 0103. Up until now, the system autocompletes the date to 0103(current year), in this case 01/03/2023. This would seem logic in some cases, but when entering a date of birth or a date in the past, this seems more strange. Also, when entering a totally random number like 1234, the system corrects it to random dates as 01/07/2025 etc. I was therefore thinking of, instead of the autocomplete, give an error message saying the date format should be DD/MM/YYYY. Or is it more user friendly to stick with the autocomplete function to the current year, and let the user change it when necessary?


  • When does the field autocomplete? When leaving it, ergo on blur?
    – Andy
    Jan 18, 2023 at 13:15
  • @Andy, yes, on blur
    – maai15
    Jan 19, 2023 at 10:37

2 Answers 2


I would say it depends on what you can make happen with the team and the budget you have, taking into account the following priority:

1. The field should not auto-complete invalid values

From Jakob Nielsen’s Error Message Guidelines

Explicit indication that something has gone wrong. The very worst error messages are those that don't exist

Further, a user wouldn’t type 1234. They might hit one wrong key or fail to hit it hard enough, resulting in one missing number like 212 instead of 2012. Help users realise what they did wrong, and to correct their mistake from there:

Preserve as much as the user's work as possible. […]

2. Make the autocomplete configurable

Yes, it is user friendly to allow the input of day and month only, it is in line with Flexibility and Efficiency of Use

Shortcuts— unseen by the novice user — speed up the interaction for the expert users such that the system can cater to both inexperienced and experienced users.

Popular spreadsheets also do the same with dates, entering 1/3 as a cell value and confirming will autocomplete to 1/3/(current year).

You can make this a configuration choice of your date input component. For example, when a birth date is expected, the developer can disable the year-autocomplete. A guideline for developers on when to choose this option would be helpful.

3. Support discovery of the default value

Instead of auto-completing empty year values, you could also opt for pre-filling the year with the current year. That way it would be obvious that only day and month need to be entered, if the year is already the right one. As the year is the last value, this should work out fine.

A date input field showing dd/mm/2023

  • Thanks for your reply! I was also thinking of making the autocomplete configurable so that it don't completes the current year when entering a birth date, f.e. But maybe it's also weird that in one place, it autocompletes (and users might become 'lazy' in entering the year) and in another one, it doesn't.
    – maai15
    Jan 25, 2023 at 7:56
  • As for your first recommendation: I agree that my scenario of entering random number is not that accurate - it would probably be that users enter only the day and month (so 02 01) without the year. We will give an error message then, saying that they also need to type in the year.
    – maai15
    Jan 25, 2023 at 8:00

Don't autocomplete, which when wrong is frustrating and leaves new users wondering how to fix it.

Instead use auto-suggest:

autosuggest date

...which keeps the user "in the loop". Now the user can determine if they're on the right track and can take a shortcut to a field completion, or realize they hit the wrong key somewhere and go back.

...date input fields are used in different types of user scenarios...

... seem logic[al] in some cases, but when entering a date of birth or a date in the past, this seems more strange.

Don't use the same support system for every date field. Build a date support system that has core features but include support for special circumstances.

For example, don't apply the "autosuggest a recent year" support to the birth date field. In that case it would only distract the user from the task.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.