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


Reply via email to