This is a fairly simple question but may have wider-reaching answers: when is it appropriate to validate entry in a wheel-based date picker (such as the iOS standard ones)?

Since there are three wheels for day, month, and year, and since a user could enter those three pieces of information in any order, there's no real way to ascertain when they're finished. Also, the three fields must have a default state, which we set to today's date.

We currently validate on the "value changed" event of the picker. So, the default state of the picker as they see it may be 31/12/2014, the user may scroll the day field first, and at that point it assesses, say, 10/12/2014, which is not allowed (as the user must be over 13 years old).

The basic issue is that we can't tell when the user has completed their entry, since they could enter day, month, then year, or year, month, then day, or perhaps the month was correct already and they didn't need to touch it, etc.

So, when would the user expect the validation (and any subsequent error message) to occur, and when is it safest to check the status of the picker?

  • Why do you not ask for year of birth first and show month/day only if necessary? That is not a general solution for this, but may be best for your particular case.
    – Crissov
    Commented Jan 1, 2015 at 8:59

5 Answers 5



A concept some term ballistics provides a good guide for this. It asserts that:

A system should not interrupt a user while performing a task, until the latest point possible or necessary.

The idea is that users formulate an action plan for a task (or subtask) and any interruption that is not essential diverges users from their original plan (which is held in the working memory).

An illustration showing 'do not disturb' sign under a set of circles representing steps in a user's mental action plan

Partial entries

The concept of ballistics is often demonstrate with clustered elements made of partials. Forms are a classic example for this (with the form field being partials), and so are dates - with the day, month and year being the partials.

Date entries

Ballistics is easy to understand in the case of date entries - a date, as far as mental models go, is made of a day, month and year. The wheels you see on some date pickers serve as interactive design solution, with various benefits attached; but they are design artefacts. You can argue that the user has not finished entering a date until all the fields are reviewed (not necessarily interacted with).

For this, some event has to signify 'I'm done entering the date'. Most commonly, this is done by either the user clicking Done, or outside the picker area (where the rest of the form might be).

And this is, in most cases at least, the right place to validate things.

Invalid dates and leap years

Another thing to consider here is that some dates can only be verified as invalid once the year has been chosen:

  • There is never 30th or 31st for February.
  • But there can be 29th in a leap year.


Things are slightly more complicated with forms. Depending on the nature of a form, users may or may not perform post-completion review. If they do (or likely to), then the correct validation trigger should be the Save button. If they don't, then on-blur (leaving the field) validation could be justified, although some argue that even without post-completion review, ballistics has it that you should not validate until the form is submitted - the users has clear intention in mind and any validation will distract from the task being performed.

  • Interesting. We don’t need to worry about the invalid dates, the iOS date picker doesn’t display those and handles that, but since the date picker is presented in-line, in a table (it slides out when the cell is tapped), there is arguably no “reviewed” state that we can detect on the user’s part. For instance, if the default year was actually their birth year, they wouldn’t have touched it, and we may not assume the entry was complete.
    – Luke
    Commented Jan 5, 2015 at 14:27
  • Despite some detailed description from you, it's still hard for me to visualise the full interaction. When do you hide the date picker?
    – Izhaki
    Commented Jan 5, 2015 at 15:00

I have zero experience of iOS listener events (if that is what they are called). This is the way I would deal with this (if I have understood the context properly). So your application requires the user to be above a certain age. Say 13, you would expect the user to enter in the year field a value equal to or less than 2002. If this is your goal showing default value as today's date isn't a wise option, you see.

If you can you should trim down the values you show to the user in the year selection field {1915(100 years of age or maximum you expect), 1916, .. 2002(13 years of age)}, its better to not allow the user to select bad data rather than have them select one and show an error.

  • In some cases, blocking a user from doing what they want can be more disruptive to their workflow (i.e. "Why isn't letting me select my birthday?!") than a retroactive message/validation, but in this case I completely agree that disallowed years should not even be shown (since I assume somewhere on the screen will be a message like "You must be 13 years old to sign up").
    – J. Dimeo
    Commented Jan 1, 2015 at 16:55
  • You're right, that sort of message is a must.
    – Nash Vail
    Commented Jan 2, 2015 at 18:29
  • There’s no such message, that information is currently delivered upon entering an invalid date. Delivering this information on-screen constantly seemed like additional clutter we didn’t need.
    – Luke
    Commented Jan 5, 2015 at 14:25

The safest (and simplest) time to check the wheel is when the user completes the form. You can also check if the spinner has been blurred (e.g. the user moves on from the selection) to give the user a more responsive experience. Both these methods ensure the user has completed the input.

In response to your comment, I mean you should determine that the user has finished by checking if they submitted the spinner, not the entire form. This can easily be done with some sort of onblur event.

  • How would you determine "when the user completes the form"? If you only validate on form submission, you could interrupt the user's workflow with a message not relevant to their current activity. Or did you mean something else by "when the user completes the form"? Commented Dec 31, 2014 at 18:41
  • Unfortunately, we currently hide the complete button until all fields have been successfully validated.
    – Luke
    Commented Dec 31, 2014 at 18:46
  • @lukech - can you add text in place of the 'complete' button that would indicate what's not done yet? Because I think preventing them from going on until all fields validate is good, but you need to explain WHY they can't go on. Commented Dec 31, 2014 at 19:45

When the user has moved on to the next field. In other words, when the user have completed the date field and moved on to the next field eg; address. This way, you would be sure that the user has decided on his selection.

  • And if this is the last field?
    – Luke
    Commented Jan 5, 2015 at 14:26
  • Not sure if it's possible to detect if the focus is out of the "date picker" i.e user has pressed "done" button? If it's technically possible then that could solve the issue.
    – Ades
    Commented Jan 6, 2015 at 3:47

You could explicitly place a button named "Done". So whenever user is done with his date selection then user will tap on done button. On action of done button you could check the validation part and show a alert with respect to your check.

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.