David,
Thank you very much for the clarification. I'm not sure people are as easily
confused as you suggest.
Using the Workeffort calendar as an example:
https://demo.hotwaxmedia.com/workeffort/control/week
If I have my locale set to English (United States) the date in the masthead is formatted the way a
US resident would expect to see it - mm/dd/yy. It's not at all confusing to be presented with a date
data entry screen that uses the mm/dd/yyyy format. I would expect it to operate that way. Someone in
Europe would expect to view and enter dates in the dd/mm/yyyy format.
Being asked to enter a date as yyyy-mm-dd is not intuitive. No other software I use requires me to
enter dates that way. If I have a choice, I would rather not do it that way.
Instead of requiring the whole world to input dates in a counter-intuitive format, I would prefer to
ask them for their locality, and then present them with a date format that they are familiar with.
Bottom line is, we have two different preferences. That's why I believe there is a need to have some
kind of a setting in OFBiz to determine which method to use. That way you can set up your server to
accept dates in the yyyy-mm-dd format, and I can set up mine to accept dates in the format my users
prefer.
-Adrian
P.S. Look at the left column of that calendar. Now THAT'S confusing!
David E Jones wrote:
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