Converting two character dates into four character dates

Question

I have an application that converts the following invalid dates, with only two-character years into a valid date format automatically while the user's filling out the form:

(NOTE: The application is only in-use by UK organisations, so the dates are all UK format only)

01/01/01 to 01/01/2001
14/05/58 to 14/05/1958
21/11/25 to 21/11/2025

It works out which century to use based on a semi-arbitrary threshold on 1950, so if a user inputs 49, they'll get 1949, but if they enter 50 they'll get 2050.

The conversion happens when the user tabs off the field and is visible immediately.

I recently received a complaint from one user who said they entered 10 and got 2010, but entered 27 and got 2027, not the 1927 they were hoping for. Their reasoning was that the 2027 was in the future, and should therefore convert to 1927 instead (because the future date was impossible).

I think in the long run, I'd love to just get rid of this functionality - I have no idea what's going to happen when we hit 2050... But in the short term, is there a way to alter the existing, basic, algorithm to make it more intuitive or user-friendly?

---

Background (not related to question)

For those interested, the user can also pick the date from a list of dates, or enter a date in a few other formats with various dashes and slashes and the system will make similar adjustments. If the system is unable to make an adjustment to the valid date format, it alerts the user via a visual cue and validation on the page fails.

The uses of the terms "valid" and "invalid" here are purely in relation to the application and have no bearing on any particular national or international date format.

Similar to this question: Date picker subtleties: Input year by using numeric keys

Answer 1

What is the context of your application? Context really matters for dates. Consider the two following situations.

1. A budgeting application where users plan spending for future years
2. A college reunion signup where users enter their graduation date

Clearly if people are planning, they would be annoyed to get a date in the past and if people are entering dates that have happened they would be annoyed to get a date in the future.

I would suggest looking at the years that your users enter in aggregate and see if you can find patterns. Your users may expect to enter dates up to ten years in the future, but also dates way into the past. In such a case, you might want to change the cutoff from "50" to "10 plus the current year". But again, it all depends on the behavior of your users in your particular context.

Answer 2

As Stephen already said: the purpose of the entered date matters a lot.

I recently developed a date entry widget that also does this (and more). It allows entering the dates in basically any format. When it recognizes the entered data as a date, it shows a passive popup under the widget with the possible matching dates for the entered text. The ordering and availability of the matches depends on users locale and the valid date limits set on the widget. So, for entering a birth date, valid dates are only dates in the past up to and including today, while for making appointments, valid dates would be dates in the future, starting from today.

That works quite well. When users enter a two digit year, they are presented with the interpreted date before even before they leave the widget, and they are able to select another than the primary date from the list of suggestions if needed. It is even possible to not enter a year at all, and still get valid suggestions. That is useful for things like appointments (close future is assumed as the most likely suggestion) or for contexts like police reports (close past is assumed for the year for the most likely suggestion).

Answer 3

Firstly, don't use two character years. We finished with the Y2K horrors, so please let's learn from them.

Then, assuming there is some critical reason to use two character years: If your users aren't entering future dates, or if those future dates are bound to something near the current date (say a few years in the future), then you should not use the method that you are using now.

You should vary the threshold in your date conversion application to some variant of the current date.

E.g. threshold = current_year + 5