Adrian Crum wrote:
2. Date/time input format. I agree that the descending format should
be retained for consistency sake. However, our users prefer to input
dates in the mm/dd/yyyy format. So, I'll leave that issue alone and
let someone else tackle the configurable data entry format that
Daniel Martinez proposed.
Yes, to do this properly would require a great deal of effort. Partly
because of that and partly because of issues with it I mentioned
earlier in terms of usability I'm against doing this, but interested
in seeing counter-arguments still...
Well, the counter argument has been presented already - some users don't
want to enter data in the yyyy-mm-dd format.
Okay, true enough, people do say that. Here's my counter-counter-argument for that: most
people THINK they want that, but they either haven't thought through the implications or
they are in denial of them. If people haven't been exposed to other options, or jumping
around to different web sites around the world and getting date formats wrong all the
time, they just won't care about such things so much. It's the old saying of "if you
only know one way it's easy to think that's the only way".
Of course, for limited scope custom applications where they know people will be
from a certain place it's not such a big deal. For the OOTB OFBiz applications,
and even for custom back-end applications in general, using a single and
consistent date/time format is important.
I'm totally fine supporting different date formats, even in the form widget if
it's done properly and there is a default of the current descending format
we're using, but for custom limited scope applications that are customer/public
facing chances are FTL files will be used for form output and simple-methods
for processing input, and we already have decent tools in those for these kinds
of things.
-David
