The format help text shows an example input based on the current date, e.g. 06/17/2008. This is ambiguous in cases such as 06/06/2008, when the day is the same as the month: if the user has to put in a past or future date like this, he or she will not know what format to use. Consequently, the site admin must provide redundant, disambiguating textual direction such as "mm/dd/yyyy".

I propose that the format help text instead show something like "Format: mm/dd/yyyy", "Format: dd/mm/yyyy - hh:mm:ss", etc. Minutes and months use the same letter, but in their contexts they shouldn't be confused. Instructing the user to enter AM/PM is a tricky case. Maybe "Format: mm/dd/yyyy - hh:mm:ss AMPM"?

Showing the current day in the correct format is a nicer-looking way of presenting this, I'll agree, but the fact that it leaves the user in a quandary ~10% of the time is a problem. Maybe there's another solution besides the scheme I mentioned? If not, I can try a patch to implement it.

Also applies to 6.x-2.x-dev.

1. date
2. text
3. site
4. no
5. yes/no

CommentFileSizeAuthor
#5 fix_format_output-271727-5.patch3 KBemattias

Comments

karens’s picture

karens commented
Version: 5.x-2.x-dev » 6.x-2.x-dev
Category: bug » feature

This is not a bug but a feature request. I agree it would be nice, but I won't get to it immediately, I'm fixing bugs now. I moved it to the D6 version since that's where feature requests should go, but this will be an easy one to backport to D5 when it gets done.

aasarava’s picture

aasarava commented

I was having the same problem, in particular with the date popup widget. The formatting instructions simply said "2010/07/01", which does not help users determine whether to use YYYY/MM/DD or YYYY/DD/MM.

I discovered that, for the date popup widget in version 6.x-2.4, the problem lies in line 259 of date_popup.module:

$sub_element['#description'] = ' '. t('Format: @date', array('@date' => date($date_format, time())));

This bit of code is taking the date format string and converting it to the actual current date. It should not do the conversion. It should be changed to simply:

$sub_element['#description'] = ' '. t('Format: @date', array('@date' => $date_format));

I suspect a similar issue exists in the other date widgets. Hope that helps!

threexk’s picture

threexk commented

aasarava: What does it show after your change? "YYYY/MM/DD" instead of "2010/07/01", or something like that? I am curious how your change solves the ambiguity for the date pop-up widget.

aasarava’s picture

aasarava commented

It shows "Y-m-d" now.

emattias’s picture

emattias commented
Category: feature » bug
Status: Active » Needs review
StatusFileSize
new fix_format_output-271727-5.patch3 KB

For some reason the strtr function inside of the t() function doesn't translate @date which is used in the #description. It worked when I used another token. I've gone through and changed @date to @date_formatted everywhere that it's run through the t function.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Issue summary: View changes
Status: Needs review » Closed (won't fix)

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.