Make date format choices less ambiguous

OK, just thought I'd bump this as we are currently the 09/09/2008, and anybody setting up a Drupal site today is having the same problem as me!

OK, so while this is undoubtedly a really minor point, on certain days of the year the UI text doesn't allow the user to make a sensible choice of date display format. Attached is a patch which attempts to make things clearer by appending descriptive text, rather than the actual date values, to the select item.

Changed title to better reflect the aim of the patch, rather than the problem.

@heather: Thanks for adding the video and the screenshot - it makes it really easy to see the difference before/after the patch.

@stella: Given the great work you've done on the customizable date formats, I think it makes sense to roll this issue into the other one, assuming you think it's worthwhile.

I still have a couple of doubts about this patch (or the approach I took, anyway):

- Adding the extra text means that the select option no longer gives an actual preview of how the date will look - is it obvious enough to the user that the text within parenthesis is only there for clarification and will not be displayed?

- Although I tried to make the descriptions a bit clearer than the PHP date formats, they're still pretty long and ugly! Would it be preferable to simplify things to say '(day/month/year)' or '(month/day/year)'? That means there's still some ambiguity - for example, 11h. is that 12/24 hour? with/without zero prefix? - but perhaps these are edge cases, for which it's not worth cluttering the interface?

Hi,

I had wondered about that approach - showing a live preview of either the current date, or the format description, outside the popup - but I don't think that would degrade very nicely without javascript, which is why I stuck with the cluttered option for this patch. I'm open to suggestions though, as the current patch isn't an ideal solution, it just makes things a bit clearer than they are.

You know, I don't set out to be difficult... I'd hosed my D7 install by messing around, so today I decided to do a clean install. And, once again, find myself prompted with a difficult choice when it comes to the date format: Hmmm, should I pick 11/11/2009, or 11/11/2009 ?

Anyway, I guess that's a sign that I should re-roll this patch...

[Edit] This is pretty much a straight re-roll of the previous patch. In the light of Stella's work on #11623: Localize date formats, this should probably be separated out into a function so that it can also be called for the form on admin/config/regional/date-time/types/add

I think I'd be confused if I went to the date/time configuration page and it wasn't showing the correct date. Or do you mean just for the descriptive text? Something like:

2009-11-11 21:34 (e.g. 2009-11-28 14:30)

...rather than:

2009-11-11 21:34 (e.g. YYYY-MM-DD hh:mm)

That could work. The 'YYYY-MM-DD' text patterns seem to be used a lot on web forms on various sites, so I think it's something that people are used to seeing, but I do accept that it makes the select box feel cluttered.

Sorry, been busy on other projects for a while. Here's a new patch which uses Stella's suggestion of using the same unambiguous example time (2:30pm on the 28th of the month), rather than 'DD/MM/YYYY etc' for the descriptive text.

This simplifies the code a bit (maybe at the expense of making the user think a bit more!), and I've broken it out into a separate function so that it can also be called for the form at 'admin/config/regional/date-time/types/add'.

Hi, sorry, I should have run it through the Coder module to catch the formatting issues. Updated patch attached.

I still have a doubt about the descriptive text though. Anybody have any feelings about which - the fixed example date, or the dd/mm/yyy - format is clearer for end-users?

... and setting back to 'needs review' to get the bot to test the patch.

@aeronox: Thanks for the feedback. I think I prefer the letter codes as well, but was hoping to get a few more opinions. When I get a moment, I'll re-roll an earlier version of the patch which uses that style of display.

I just re-installed my D7 test site, and using the 28th of the month for the example date is really confusing when it is actually the 28th, because it just makes it look like the time is incorrect. Using the 28th also makes it impossible to distinguish between D and DD for the day display so, all things considered, I think it's back to the 'DD/MM/YYYY' style of descriptive text. New patch attached.

Just re-rolled that patch against the latest version of Head, as it's been a while.

Oops, please ignore #25. New patch attached with the line I missed in the previous one, and created at Drupal root.

Rerolled to chase head as we're 05/05 today. Patch and demo image attached.

Thanks for the feedback. I kind of agree that displaying the month name as text in among the DD/MM/YYYY lettercodes looks a little strange but, as you say, it's not easy to find replacements that won't cause even more confusion.

The very first patch I submitted showed the PHP notation being used, but this is user facing interface text we're talking about here, and so I really think we need to make the display friendlier and easier to read, otherwise we might as well just point them to the source code. If users have added custom date formats, then they probably understand the PHP notation, but otherwise something more human-readable seems preferable.

I'm open to replacing the month names with something else, but is there a standard for this? Anything with DDD or DY might cause confusion with the DD/MM/YY replacements and using 'Month' might work, but the shortened month name would be 'Mon.' which looks like a shortened version of 'monday', and that's before we think about i18n!

I originally submitted this patch because of the ambiguous numeric day/month display, and I think there is merit in keeping things simple, but if we can reach some kind of consensus about how to replace the day/month text, I'll happily update the patch.

Perhaps we should use Dries' birthday as the date?! I still don't really agree that dd/mm/yy is more confusing than an arbitrary date - as I see this format used almost every time a web site asks for my date of birth, or travel date, or whatever - but I'll go with what people think works best.

As for pushing this back to D8. I'd be disappointed if that meant that a simple UI bug is going to have to wait another 2 years or so to get fixed. This issue is already over 2 years old - originally submitted against D6 - and, while I'm the first to admit that the patch isn't perfect (display of month names/numbers is definitely inconsistent), if a perfect solution to all possible edge cases is what's required then it'll never get in, and we might as well set this as won't fix and forget about it. Meanwhile, maybe I should wait until sunday - 10/10/10 - and reroll the patch?

Just a thought, but if Jan 15, 2001 is used as the reference date and somebody chooses the 2 digit format for the date - 01/15/01 or 15/01/01 - then we're back to square one as far as ambiguity is concerned. So, if a reference date is the preferred route, then 12/31/1969 might be a better option.