7

I don't want to force users to use only mm/dd/yyyy format on my website.

My case: User will be able to choose which date format he prefers on the website ( calendars, tables and so on):
12.30.2016
12/30/2016
Dec 30 2016
30 Dec 2016

I don't want to put any restrictions on date input format the user can ENTER ( regardless of whatever date format he will use for display). So any input will be valid
12302016
12.30.2016
12/30/2016
30Dec2016
30 Dec 2016
30 December 2016
30 Dec (automatically will place the current year)

Q 1:
Is it a good practice to do stuff like that ( I don't see any reasonable limitation to force the user to enter only specific date format.)

Q 2:
Is it a good idea to replace the date format to the user's set custom format after he moves to the next input? (e.g. Users enter "30122016" but when he moves to another field the date will be replaced with 30 Dec 2016)

The product is made only for US market

  • How important are dates in your website? Unless they are crucial to every journey, it seems strange to not use a consistent format that all users can understand. – Midas Apr 16 '16 at 16:38
  • 1
    @Midas mostly events and bookings. So users always use dates in their workflow. But 1/3 of all the time they actually entering them via the forms. – ProgZi Apr 16 '16 at 17:13
  • Are you suggesting that (a) the user select a format before entering the date? Or (b) that the user enter the date in whatever format they wish and the system figures it out? (I hate (a) and love (b).) – Ken Mohnkern Jun 17 '16 at 13:36
1

If you want, it's ok to let users choose their own format for displaying dates (after all, if they don't want this feature they can always stick to the default option).

However, you should always present the same GUI widget to choose a date: either

1) a calendar, or

2) three drop-down menus with day, full name of month, and 4-digit year

This would eliminate all ambiguity in the chosen date. Afterwards you can show the date in the user-defined format.

| improve this answer | |
0

30 Dec 2016 is unambiguous, understandable and acceptable to all English speakers, so there usually is no real need to offer customizable date display format when you use this. Dec 30, 2016 is a little worse.

On the Internet and in English software (being the default and fallback language for many non-natives and travelers), an all-numeric, three-part Gregorian date with two equal separators shall always use strict order of items, i.e. either big or little endian, never a mix. The separators may also slightly favor one endianness over the other, e.g. big/small (think URL paths) and small.big. (but big.float).

If you want to preserve spoken US order, always either use two different separators (possibly including ordinal two-letter suffixes) or verbal months. If you ever need to shorten the year to two digits add an apostrophe in front.

Forbidden numeric date display formats

These are inherently broken and put a higher cognitive load on the reader than necessary.

  • MMDDYYYY: 12/30/2016, 12.30.2016, 12-30-2016
  • YYYYDDMM: 2016/30/12, 2016.30.12, 2016-30-12
  • DDMMYY: 30/12/16, 30.12.16, 30-12-16
  • MMDDYY: 12/30/16, 12.30.16, 12-30-16
  • YYMMDD: 16/12/30, 16.12.30, 16-12-30
  • YYDDMM: 16/30/12, 16.30.12, 16-30-12

(Least bad ones highlighted.)

Discouraged numeric date display formats

These are inherently fine, but can be ambiguous without proper context due to proliferation of forbidden formats.

  • DDMMYYYY: 30/12/2016, 30.12.2016, 30-12-2016
  • DDMMYY: 30/12/’16, 30.12.’16, 30-12-’16
  • YYMMDD: ’16/12/30, ’16.12.30, ’16-12-30
  • MMDDYYYY: 12/30, 2016
  • MMDD: 12/30, -12-30
  • DDMM: 30.12.
  • YYYYMM: 2016/12, 2016-12 (can both be mistaken as year ranges if YY < 12)
  • MMYYYY: 12/2016, 12, 2016

Acceptable numeric date display formats

  • YYYYMMDD: 2016/12/30, 2016-12-30, 2016.12.30

As you can see, the only acceptable all-numeric formats are not the ones your target group is well familiar with, so don’t use one!

A free text date input should recognize any unambiguous value (including forbidden formats and seemingly redundant ones with day of the week), but it may also inform the user about a preferred format and valid date range (which may also help to choose the interpretation). It should provide immediate feedback to the user to verify the parsed result and, especially if there was any uncertainty, provide the means for the user to correct the data at any time.

| improve this answer | |
0

Sounds like there are two problems here packaged as one.

Displaying dates for easy reading

As Crissov mentioned in his answer, there are some date formats that are more difficult to understand than others. What you should do is to choose the most commonly used date formats and present these as options for the user.

e.g.

  • Jan 1 2016 (North America)
  • 1 Jan 2016 (Europe)
  • 2016-01-01 (Asia / elsewhere)

As long as the month, day, year is ordered in the way the user is familiar with. Whether you use slashes, or dashes or dots etc matters very little.

Allow easy date entry

The best input should be format agnostic. The user can enter the date is any format (e.g. Jan 1, 01-01-2016, 2016.1.1) and the system should understand and format it in the date format they've chosen in the previous step.

| improve this answer | |
  • So a user entering 3/4/16 is interpreted as April 3 if the user has previously chosen "Europe" and March 4 if he chose "North America"? Would you recommend changing the input date to the display format? (That is, changing 3/4/16 on entry so it's shown as March 4 2016?) – Andrew Leach Aug 20 '16 at 9:01
  • @AndrewLeach Yes to both questions. If the setting is "European" date format, "3/4/16" would be replaced with Apr 3 2016. If the setting is "North American" format, it would be replaced with Mar 4 2016. Users rarely enter dates in both formats. It's also easier to spot a mistake when you spell out the month. – nightning Aug 22 '16 at 16:16
0

Most important is for users to receive clear feedback on wether they have entered it in succesfully.

Zotero desktop for the Mac does this well by telling the user how their input is interpreted. Note that the user doesn't have to pick format, simply enter a value in the date field.

Zotero Example 1

Zotero date input example 1

Zotero Example 2

Zotero date input example 2

Zotero Example 3

Zotero date input example 3

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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