Adrian,
Please step outside of yourself a little bit and realize that your experiences are not the same as the whole world and that perhaps you're not in a position to speak for the whole world. Also, which systems or even types of systems have you used?
OFBiz is (or aspires to be!) a global friendly corporate scale ERP system. In
my view this makes the two things we've been discussing contradictory:
1. properly support multiple time zones (important for global ERP systems,
doesn't matter for USA or Europe only desktop small business apps)
2. use funny local customs for date format (bad for global ERP systems, good
for USA or Europe only desktop small business apps)
Some places in the world don't have a consistent standard. In the USA my
experience has been there are multiple standards, though yes the defacto one is
month/day/year - even though ordering things that way makes NO sense whatsoever.
Anyway, how long does it takes for a user to get the idea of a descending date/time
format? A few minutes maybe? How annoying is it to have different entry formats in
different places (it will be a fair bit of work to make them all consistently different
in OFBiz now...)? Even if they are all consistent, how annoying is it to produce
different documentation and screen shots for different places around the world, even if
nothing is different other than this? How confusing is it for "George" in a
support call center in India to take calls from all over the world and have to figure out
what the user is seeing on the other end and why they're getting a date format error or
worse some other obscure error or a non-error but unexpected result when the user guesses
wrong about the format? What about the poor users (like me!) who travel and use web sites
around the world and always have to guess about the date format, sometimes getting it
wrong and would really just like to have thing
s be consistent and in a format that is sortable and makes sense so I can think
of time increments largest to smallest?
Of course, we should really give this some time and let others express their
opinions. I also realize I've only experienced a small corner of the world, but
that is the main reason I have for keeping this consistent and as standard as
possible for the ERP world.
-David
Adrian Crum wrote:
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
