Workeffort Calendar Progress

[Adrian Crum]

I have been working on making the Workeffort calendar support user-selected locales and time zones.

Steps accomplished so far:

1. Fixed date computation bug in the calendar code
2. Provided a time zone drop-down list and user time zone selection persistence
3. Re-write the bsh and ftl files to support user-selected time zones and locales. This step was a
snap because I ported my calendar program files back to OFBiz. This hasn't been submitted yet,
because there are some blockers...

Steps that need to be done:

4. Make the user selected java.util.TimeZone object available to services and screen renderers. The
code has been submitted (https://issues.apache.org/jira/browse/OFBIZ-1117) but not committed yet.
5. Modify the form widget to support user selected time zones and locales. Currently the form widget
forces the user to input date/time in the server's format and time zone. I haven't started on that yet.
6. Modify Workeffort calendar form widgets to use the new time zone/locale support from #5.

I hoped to get more work done on this during the holiday, but as luck would have it, my internet
connection died yesterday and it won't be working again until Friday.

-Adrian

[David E Jones]

It's great to see effort going into this, so thanks Adrian!


Adrian Crum wrote:
> 5. Modify the form widget to support user selected time zones and
> locales. Currently the form widget forces the user to input date/time in
> the server's format and time zone. I haven't started on that yet.

I'm not totally sure what you have in mind here, but I'll keep an eye out for more info from you and see if I can help out.

IMO the main priority for this is to properly support time zones. I'm still a big fan of the descending date/time format instead of using localized formats. The problem with those is that there are either too few or too many "standards" and so unless you show a format string with every input box it can be VERY confusing and frustrating to figure out how to type in a date and/or time. We also need to keep in the mind that the popup window for date selection would need to have something passed into it so it knows how to format the date/time string based on the selection.

So yeah, in general I'm a big fan of using the descending format everywhere, even consumer/public facing applications (at least as a default, there are certainly tools to support other formats as needed for custom UIs).

-David

[Jacques Le Roux]

David,

Please can you explain what is a descending date/time format ? I'm a bit lost...

Thanks

Jacques

De : "David E Jones" <[hidden email]>

>
> It's great to see effort going into this, so thanks Adrian!
>
>
> Adrian Crum wrote:
> > 5. Modify the form widget to support user selected time zones and
> > locales. Currently the form widget forces the user to input date/time in
> > the server's format and time zone. I haven't started on that yet.
>
> I'm not totally sure what you have in mind here, but I'll keep an eye out for more info from you and see if I can help out.
>
> IMO the main priority for this is to properly support time zones. I'm still a big fan of the descending date/time format instead

of using localized formats. The problem with those is that there are either too few or too many "standards" and so unless you show a
format string with every input box it can be VERY confusing and frustrating to figure out how to type in a date and/or time. We also
need to keep in the mind that the popup window for date selection would need to have something passed into it so it knows how to
format the date/time string based on the selection.
>
> So yeah, in general I'm a big fan of using the descending format everywhere, even consumer/public facing applications (at least as
a default, there are certainly tools to support other formats as needed for custom UIs).
>
> -David
>

[Jacopo Cappellato]

Jacques,

I think that David refers to the yyyy-mm-dd... format, that can be
simply sorted as a string keeping the correct time sequence.
This is actually a standard de facto in ERP systems (together with the
numer representation, with the same features, of yyyymmdd... as integer)

Jacopo

Jacques Le Roux wrote:

> David,
>
> Please can you explain what is a descending date/time format ? I'm a bit lost...
>
> Thanks
>
> Jacques
>
> De : "David E Jones" <[hidden email]>
>> It's great to see effort going into this, so thanks Adrian!
>>
>>
>> Adrian Crum wrote:
>>> 5. Modify the form widget to support user selected time zones and
>>> locales. Currently the form widget forces the user to input date/time in
>>> the server's format and time zone. I haven't started on that yet.
>> I'm not totally sure what you have in mind here, but I'll keep an eye out for more info from you and see if I can help out.
>>
>> IMO the main priority for this is to properly support time zones. I'm still a big fan of the descending date/time format instead
> of using localized formats. The problem with those is that there are either too few or too many "standards" and so unless you show a
> format string with every input box it can be VERY confusing and frustrating to figure out how to type in a date and/or time. We also
> need to keep in the mind that the popup window for date selection would need to have something passed into it so it knows how to
> format the date/time string based on the selection.
>> So yeah, in general I'm a big fan of using the descending format everywhere, even consumer/public facing applications (at least as
> a default, there are certainly tools to support other formats as needed for custom UIs).
>> -David
>>

[Jacques Le Roux]

Ha I see, thanks Jacopo ! Yes this should be the only authorised date format everywhere indeed (not only in OFBiz I mean :o)

Jacques

De : "Jacopo Cappellato" <[hidden email]>

> Jacques,
>
> I think that David refers to the yyyy-mm-dd... format, that can be
> simply sorted as a string keeping the correct time sequence.
> This is actually a standard de facto in ERP systems (together with the
> numer representation, with the same features, of yyyymmdd... as integer)
>
> Jacopo
>
> Jacques Le Roux wrote:
> > David,
> >
> > Please can you explain what is a descending date/time format ? I'm a bit lost...
> >
> > Thanks
> >
> > Jacques
> >
> > De : "David E Jones" <[hidden email]>
> >> It's great to see effort going into this, so thanks Adrian!
> >>
> >>
> >> Adrian Crum wrote:
> >>> 5. Modify the form widget to support user selected time zones and
> >>> locales. Currently the form widget forces the user to input date/time in
> >>> the server's format and time zone. I haven't started on that yet.
> >> I'm not totally sure what you have in mind here, but I'll keep an eye out for more info from you and see if I can help out.
> >>
> >> IMO the main priority for this is to properly support time zones. I'm still a big fan of the descending date/time format

instead
> > of using localized formats. The problem with those is that there are either too few or too many "standards" and so unless you
show a
> > format string with every input box it can be VERY confusing and frustrating to figure out how to type in a date and/or time. We
also
> > need to keep in the mind that the popup window for date selection would need to have something passed into it so it knows how to
> > format the date/time string based on the selection.
> >> So yeah, in general I'm a big fan of using the descending format everywhere, even consumer/public facing applications (at least
as
> > a default, there are certainly tools to support other formats as needed for custom UIs).
> >> -David
> >>
>

[David E Jones]

It's the format we use everywhere. Descending means start with the biggest unit and continue to the smallest (ie year, month, day, hour, minute, second, partial second).

-David


Jacques Le Roux wrote:

> David,
>
> Please can you explain what is a descending date/time format ? I'm a bit lost...
>
> Thanks
>
> Jacques
>
> De : "David E Jones" <[hidden email]>
>> It's great to see effort going into this, so thanks Adrian!
>>
>>
>> Adrian Crum wrote:
>>> 5. Modify the form widget to support user selected time zones and
>>> locales. Currently the form widget forces the user to input date/time in
>>> the server's format and time zone. I haven't started on that yet.
>> I'm not totally sure what you have in mind here, but I'll keep an eye out for more info from you and see if I can help out.
>>
>> IMO the main priority for this is to properly support time zones. I'm still a big fan of the descending date/time format instead
> of using localized formats. The problem with those is that there are either too few or too many "standards" and so unless you show a
> format string with every input box it can be VERY confusing and frustrating to figure out how to type in a date and/or time. We also
> need to keep in the mind that the popup window for date selection would need to have something passed into it so it knows how to
> format the date/time string based on the selection.
>> So yeah, in general I'm a big fan of using the descending format everywhere, even consumer/public facing applications (at least as
> a default, there are certainly tools to support other formats as needed for custom UIs).
>> -David
>>
>

[Daniel Martínez-4]

Thanks a lot Adrian for this work. I am really interested in it.

David E Jones escribió:

>
> I'm not totally sure what you have in mind here, but I'll keep an eye
> out for more info from you and see if I can help out.
>
> IMO the main priority for this is to properly support time zones. I'm
> still a big fan of the descending date/time format instead of using
> localized formats. The problem with those is that there are either too
> few or too many "standards" and so unless you show a format string
> with every input box it can be VERY confusing and frustrating to
> figure out how to type in a date and/or time. We also need to keep in
> the mind that the popup window for date selection would need to have
> something passed into it so it knows how to format the date/time
> string based on the selection.

IMO descending date/time is great for queries on databases but not for
human input. Most ERPs I've seen have support for localized formats.

I agree however about the "too many standards" problem. To solve this
either a properties file with "locale-date_format" entries or a new
entity with this info could be used.

WDYT?

--
Daniel

[Adrian Crum]

David E Jones wrote:

> Adrian Crum wrote:
>
>> 5. Modify the form widget to support user selected time zones and
>> locales. Currently the form widget forces the user to input date/time
>> in the server's format and time zone. I haven't started on that yet.
>
>
> I'm not totally sure what you have in mind here, but I'll keep an eye
> out for more info from you and see if I can help out.
>
> IMO the main priority for this is to properly support time zones. I'm
> still a big fan of the descending date/time format instead of using
> localized formats. The problem with those is that there are either too
> few or too many "standards" and so unless you show a format string with
> every input box it can be VERY confusing and frustrating to figure out
> how to type in a date and/or time. We also need to keep in the mind that
> the popup window for date selection would need to have something passed
> into it so it knows how to format the date/time string based on the
> selection.
>
> So yeah, in general I'm a big fan of using the descending format
> everywhere, even consumer/public facing applications (at least as a
> default, there are certainly tools to support other formats as needed
> for custom UIs).
>
> -David

David,

There are two date/time issues that need to be addressed in the form widget:

1. Converting Strings to/from Timestamps using the user's time zone. I'm thinking this is something
that needs to be controlled by a widget XML element attribute - since there may be cases where the
server's time zone should be used. It would be best to have the widget default to the server's time
zone (for backward compatibility) and have time zone support switched on through an XML element
attribute.

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.

-Adrian

[Daniel Martínez-4]

Adrian,

Is there an ofbiz issue already setup for this? Or should I create a new
one?

Thanks,
--
Daniel

Adrian Crum escribió:
> 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.

[Adrian Crum]

No, there is no issue set up yet.

Daniel Martínez wrote:

> Adrian,
>
> Is there an ofbiz issue already setup for this? Or should I create a new
> one?
>
> Thanks,
> --
> Daniel
>
> Adrian Crum escribió:
>
>>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.
>
>
>

[David E Jones]

As Adrian said there isn't one, but I don't think we're ready for one either. The dev mailing list is much better for, and is really meant for, discussions like this.

-David


Daniel Martínez wrote:

> Adrian,
>
> Is there an ofbiz issue already setup for this? Or should I create a new
> one?
>
> Thanks,
> --
> Daniel
>
> Adrian Crum escribió:
>> 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.
>

[Daniel Martínez-4]

What do you mean ready for it?

I was thinking about beginning some development for it to get done, not
for discussing it (at least not discussing IF it should get done but HOW
should it get done). If no one else is interested on this I will
eventually submit a patch and then you can discuss (through this list)
if it should be commited or not.

Please correct me if my reasoning is wrong.

Regards,
--
Daniel

David E Jones escribió:

>
> As Adrian said there isn't one, but I don't think we're ready for one
> either. The dev mailing list is much better for, and is really meant
> for, discussions like this.
>
> -David
>
>
> Daniel Martínez wrote:
>> Adrian,
>>
>> Is there an ofbiz issue already setup for this? Or should I create a new
>> one?
>>
>> Thanks,
>> --
>> Daniel
>>
>> Adrian Crum escribió:
>>> 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.
>>

[David E Jones]

Adrian Crum wrote:
> There are two date/time issues that need to be addressed in the form
> widget:
>
> 1. Converting Strings to/from Timestamps using the user's time zone. I'm
> thinking this is something that needs to be controlled by a widget XML
> element attribute - since there may be cases where the server's time
> zone should be used. It would be best to have the widget default to the
> server's time zone (for backward compatibility) and have time zone
> support switched on through an XML element attribute.

Right now I'd say we go ahead and default it to use the users time zone, in other words interpret any user input as time in their own time zone - or even change all date/time inputs to allow the user to specify the time zone (which IMO would be a great enhancement) and have it default to the user's preferred time zone. There are various system time stamps that should be in the system's time zone, but for the most part when a user enters data we can assume (and default to) that they mean it in terms of their own time zone.

Note that from an infrastructure level this can be a little complicated, but it's not too bad, and I agree it's worth doing. This would make OFBiz a much more global-friendly

> 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...

-David

[Daniel Martínez-4]

Hi David,

Do you mean that dates from i.e. OrderItem will be stored in the
database under the user timezone?

David E Jones escribió:
> Right now I'd say we go ahead and default it to use the users time
> zone, in other words interpret any user input as time in their own
> time zone - or even change all date/time inputs to allow the user to
> specify the time zone (which IMO would be a great enhancement) and
> have it default to the user's preferred time zone. There are various
> system time stamps that should be in the system's time zone, but for
> the most part when a user enters data we can assume (and default to)
> that they mean it in terms of their own time zone.

[David E Jones]

Daniel,

I'm sensing a question behind this question, but I'm not sure what it is...

What does OrderItem have to do with this?

-David


Daniel Martínez wrote:

> Hi David,
>
> Do you mean that dates from i.e. OrderItem will be stored in the
> database under the user timezone?
>
> David E Jones escribió:
>> Right now I'd say we go ahead and default it to use the users time
>> zone, in other words interpret any user input as time in their own
>> time zone - or even change all date/time inputs to allow the user to
>> specify the time zone (which IMO would be a great enhancement) and
>> have it default to the user's preferred time zone. There are various
>> system time stamps that should be in the system's time zone, but for
>> the most part when a user enters data we can assume (and default to)
>> that they mean it in terms of their own time zone.
>

[Daniel Martínez-4]

David,

Sorry for the dumb question.

OrderItem was just an example.

I thought you meant storing dates in the user locale in the database. Of
course the answer is no.
--
Daniel

David E Jones escribió:

>
> Daniel,
>
> I'm sensing a question behind this question, but I'm not sure what it
> is...
>
> What does OrderItem have to do with this?
>
> -David
>
>
> Daniel Martínez wrote:
>> Hi David,
>>
>> Do you mean that dates from i.e. OrderItem will be stored in the
>> database under the user timezone?
>>
>> David E Jones escribió:
>>> Right now I'd say we go ahead and default it to use the users time
>>> zone, in other words interpret any user input as time in their own
>>> time zone - or even change all date/time inputs to allow the user to
>>> specify the time zone (which IMO would be a great enhancement) and
>>> have it default to the user's preferred time zone. There are various
>>> system time stamps that should be in the system's time zone, but for
>>> the most part when a user enters data we can assume (and default to)
>>> that they mean it in terms of their own time zone.

[Adrian Crum]

David E Jones wrote:

> Adrian Crum wrote:
>
>> There are two date/time issues that need to be addressed in the form
>> widget:
>>
>> 1. Converting Strings to/from Timestamps using the user's time zone.
>> I'm thinking this is something that needs to be controlled by a widget
>> XML element attribute - since there may be cases where the server's
>> time zone should be used. It would be best to have the widget default
>> to the server's time zone (for backward compatibility) and have time
>> zone support switched on through an XML element attribute.
>
>
> Right now I'd say we go ahead and default it to use the users time zone,
> in other words interpret any user input as time in their own time zone -
> or even change all date/time inputs to allow the user to specify the
> time zone (which IMO would be a great enhancement) and have it default
> to the user's preferred time zone. There are various system time stamps
> that should be in the system's time zone, but for the most part when a
> user enters data we can assume (and default to) that they mean it in
> terms of their own time zone.

Cool! It would be simpler to make that the default behavior. I had thought about the selectable
time-zone per input idea. Maybe that can come after the basic implementation is in place.

> Note that from an infrastructure level this can be a little complicated,
> but it's not too bad, and I agree it's worth doing. This would make
> OFBiz a much more global-friendly

I don't think it will be that complicated. If we make the user's TimeZone object as ubiquitous as
their Locale object, then it can be used to run date/time conversions though the UtilDateTime methods.

>> 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.

-Adrian

[David E Jones]

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

[Adrian Crum]

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
>
>

[David E Jones]

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
>>
>>