I am working on a project where there is a datepicker field. Users are not allow to choose past dates(only current and future dates allow). Right now we have two options to design this, which is either to :

  1. Disable past dates from the datepicker
  2. Allow user to choose past dates and display error message if user choose past date

Which option should I choose and what are the supporting reasons? Need concrete reasoning to convince other team members.

Any advice, help or article related would be a great help. Thanks in advance!

  • 2
    Can users copypaste into the datepicker field or do they have to use the 'calendar'?
    – Zikato
    Commented Sep 7, 2016 at 8:55
  • 8
    <input type="date" min="2016-09-07" /> seems just fine to me - the browser will show a calendar using native UI (which is very important on mobile devices) and handles validation for you. Commented Sep 7, 2016 at 14:08

5 Answers 5


1 is the better option as you are not making the user do a set of actions that would lead to error message. It's better to avoid the chance of an error occurring rather than let the user do the error and agitate the user that they did something wrong.

you could disable the dates and show a tool tip if the user tries to select the disabled dates



As others have said, it's better to disable past dates to minimise the risk of bad data, however you should also factor in that sometimes things don't work as expected and still validate the data.

If you just blindly accepted the input, what would happen if the user found a way of entering a date in the past? If they find a bug and exploit it, then you don't check for the validity or let them know they have done something wrong, they will probably do it again in the future and not know they shouldn't be.

In a nutshell:

  • Restrict the range in the date picker to visually discourage them from using past or invalid dates
  • Always check their input and let them know if they have done something wrong.
  • 8
    People use the internet around midnight, or finish a task the next day - no need to 'find and exploit bugs'.
    – Sanchises
    Commented Sep 7, 2016 at 9:57
  • @sanchises very true. Never thought about something as simple as a date change-over.
    – gabe3886
    Commented Sep 7, 2016 at 10:02
  • 4
    @sanchises I think that we should not let people use the internet around midnight, they cannot be up to any good then. And finishing a task the next day is right out.
    – user67695
    Commented Sep 7, 2016 at 14:02
  • 1
    Obligatory don't forget to validate server side as well.
    – DasBeasto
    Commented Sep 7, 2016 at 17:46

Option 1 is much better than option 2 because:

  • It provides visual cue that the past dates cannot be selected. Consequently, it prevents errors (selecting past date) from being made. It's error free.

  • Showing an error message has high interaction cost - if a user selects wrong date, an error message will appear. This makes the user to read, and comprehend the message, which takes cognitive resources. After that he has to click to close the message, again that 1 unnecessary click that could be avoided. Compared to just disabling the past dates where the user might not click at all because the fields are disabled.

Basically you can say that closing an error message requires more cognitive resources (cognitive load) than constraining the options of the user. And that is in compliance with the usability heuristic to minimize short-term memory load of users.


Both... And...
There might be a use case where some users are able to select dates in the past, based on higher authority, or performing necessary maintenance. So, whatever controls that ability should control all ways of entering data, and allow for both situations to coexist.

Programming in limitations usually means that you have to program them out later. Try to make everything data-driven and configurable to the greatest extent possible. Then you can change something in one place and it applies everywhere. (No advice for you on how to make your brain that clever.)


Prevent errors wherever possible

Jakob Nielsen said it well in his 10 Heuristics for UI Design:

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

The goal of your design is to make errors an edge case. They will happen, but you want it to be a rare occurrence.

As someone else here noted, it's good to support native calendar widgets on mobile in most cases. But if you design your own (which you'll want on desktop), make the limitation clear. You may even need some kind of hint in the UI explaining why there are no past dates.

Errors will happen

As I said above, you often can't avoid errors entirely with any component. For example, does your system append parameters to the URL to specify the date range? That's a good thing for sharing views with others, but what if the URL is followed later and the range has become invalid?

You need well-crafted error messages that are succinct enough that users won't just ignore them (how fast do you hit esc?) but descriptive enough that they know exactly what to do next.

  • @nocomprende point taken. "Impossible" is impossible, but there's probably a better word. Commented Sep 8, 2016 at 14:49
  • The Impossible Dream: "a perfect UI is certain because it is impossible."
    – user67695
    Commented Sep 8, 2016 at 14:59

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.