Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

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

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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" <jo...@hotwaxmedia.com>
>> 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
>>
> 

Re: Workeffort Calendar Progress

[Jacques Le Roux <ja...@les7arts.com>]

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" <ti...@sastau.it>
> 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" <jo...@hotwaxmedia.com>
> >> 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
> >>
>

Re: Workeffort Calendar Progress

[Jacopo Cappellato <ti...@sastau.it>]

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" <jo...@hotwaxmedia.com>
>> 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
>>

Re: Workeffort Calendar Progress

[Jacques Le Roux <ja...@les7arts.com>]

David,

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

Thanks

Jacques

De : "David E Jones" <jo...@hotwaxmedia.com>
>
> 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
>

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

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.

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

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.

Re: Workeffort Calendar Progress

[Jacques Le Roux <ja...@les7arts.com>]

This is really a confusing theme.

On one hand, as an "informaticien" (it's the word for software engineer here in France)  I would love to see everybody in this world
using an unique sortable date format. I like to see order in things and yes I'm very puzzled too with all these date formats.

On the other hand it's obvious that we are not missionaries and that people do like using what they have learnt at school or at
work. In every days life people use date formats to sign check, etc. How can we expect them to get rid of their common locale habits
using a software ? For them it's only a tool, like a pencil or such...

So I agree with Adrian last paragraph below (I'm not sure of what David means by "This seems strangely familiar...")

Jacques

De : "David E Jones" <jo...@hotwaxmedia.com>
>
>
> Adrian Crum wrote:
> > David E Jones wrote:
> >> 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.
> >
> > lol - That's the position *you've* taken, not me. Daniel and I have
> > expressed a different view than yours, and you're trying to argue that
> > yours is the "best" one. I'm trying to make a point that we have two
> > different requirements, therefore OFBiz should attempt to accomodate
> > both requirements. You're saying that the OFBiz users who have different
> > requirements than yours don't matter, or that they aren't well traveled,
> > or they are confused and don't know what's best for them.
>
> I may just be writing this because I'm damn sick (no solid food for 6 days now) and in a bad mood... but I DARE you to back up the
words your speaking on my behalf with text from what I actually wrote, especially the "You're saying that the OFBiz users who have
different requirements than yours don't matter". If I mis-wrote that badly, I should just give up now.
>
> >  > Also, which systems or
> >> even types of systems have you used?
> >> OFBiz is (or aspires to be!) a global friendly corporate scale ERP
> >> system.
> >
> > {snip]
> >
> >> 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?
> >
> > Let's apply the same argument to currency. Why should we support
> > anything other than US dollars? It shouldn't take long for users
> > accustomed to other currency to adapt, right? Why does OFBiz format
> > currency according to locale? Aren't those currency formatting
> > differences "funny local customs" too?
>
> False analogy.
>
> > I think you're making this a bigger issue than it needs to be. All of
> > the date/time formatting has to be run through some kind of conversion
> > method anyway, so why not add to that method a simple if statement that
> > checks a property in general.properties? If the server is set up to use
> > yyyy-mm-dd formatting, then use it. Otherwise, format the date/time
> > according to the user's locale. It doesn't require any additional
> > programming effort. Problem solved. Everybody's happy.
>
> This seems strangely familiar...
>
> -David
>

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

Adrian Crum wrote:
> David E Jones wrote:
>> 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.
> 
> lol - That's the position *you've* taken, not me. Daniel and I have 
> expressed a different view than yours, and you're trying to argue that 
> yours is the "best" one. I'm trying to make a point that we have two 
> different requirements, therefore OFBiz should attempt to accomodate 
> both requirements. You're saying that the OFBiz users who have different 
> requirements than yours don't matter, or that they aren't well traveled, 
> or they are confused and don't know what's best for them.

I may just be writing this because I'm damn sick (no solid food for 6 days now) and in a bad mood... but I DARE you to back up the words your speaking on my behalf with text from what I actually wrote, especially the "You're saying that the OFBiz users who have different requirements than yours don't matter". If I mis-wrote that badly, I should just give up now.

>  > Also, which systems or
>> even types of systems have you used?
>> OFBiz is (or aspires to be!) a global friendly corporate scale ERP 
>> system.
> 
> {snip]
> 
>> 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?
> 
> Let's apply the same argument to currency. Why should we support 
> anything other than US dollars? It shouldn't take long for users 
> accustomed to other currency to adapt, right? Why does OFBiz format 
> currency according to locale? Aren't those currency formatting 
> differences "funny local customs" too?

False analogy.

> I think you're making this a bigger issue than it needs to be. All of 
> the date/time formatting has to be run through some kind of conversion 
> method anyway, so why not add to that method a simple if statement that 
> checks a property in general.properties? If the server is set up to use 
> yyyy-mm-dd formatting, then use it. Otherwise, format the date/time 
> according to the user's locale. It doesn't require any additional 
> programming effort. Problem solved. Everybody's happy.

This seems strangely familiar...

-David

Re: Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

David E Jones wrote:
> 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.

lol - That's the position *you've* taken, not me. Daniel and I have expressed a different view than 
yours, and you're trying to argue that yours is the "best" one. I'm trying to make a point that we 
have two different requirements, therefore OFBiz should attempt to accomodate both requirements. 
You're saying that the OFBiz users who have different requirements than yours don't matter, or that 
they aren't well traveled, or they are confused and don't know what's best for them.

 > Also, which systems or
> even types of systems have you used?
> OFBiz is (or aspires to be!) a global friendly corporate scale ERP 
> system.

{snip]

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

Let's apply the same argument to currency. Why should we support anything other than US dollars? It 
shouldn't take long for users accustomed to other currency to adapt, right? Why does OFBiz format 
currency according to locale? Aren't those currency formatting differences "funny local customs" too?

I think you're making this a bigger issue than it needs to be. All of the date/time formatting has 
to be run through some kind of conversion method anyway, so why not add to that method a simple if 
statement that checks a property in general.properties? If the server is set up to use yyyy-mm-dd 
formatting, then use it. Otherwise, format the date/time according to the user's locale. It doesn't 
require any additional programming effort. Problem solved. Everybody's happy.

> Of course, we should really give this some time and let others express 
> their opinions.

I agree. We've both made our points. I'm done.

-Adrian

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

David,

While I'd love to see all people in the world using this sortable date
format, GMT time and speaking spanish :P, I have to face reality in form
of the users' locale.

David E Jones escribió:
>
> 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)
I also agree with you that lack of timezone support is a major problem
which can break havoc in form of database consistency and scheduling
problems.
>
> 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.
You can take Excell. While not a global-focused ERP, excell files are
exchanged everyday through mail between different locales. Date formats
are viewed according to the user locale (which can also be configured)
and everybody is happy. Why can't ofbiz support this?
>
> Anyway, how long does it takes for a user to get the idea of a
> descending date/time format? A few minutes maybe?
How much a discussion like this will take with a manager? How many more
complaints (translated to effort in meetings) will the system suffer
from this issue?
> 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?
Well, the language will be different also (in non-english countries), so
the screenshots will have to be changed anyway.
> 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
It should not be a problem is George has a tool to select the correct
user's locale (as ofbiz has).

How many poor users (like me) have to suffer global ecommerce sites
(like amazon) not respecting my locale (not only dates in mm/dd/yyyy
format but also lack of support for accents, unicode, etc ...)?
>
> 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.
--
Daniel

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

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

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Workeffort Calendar Progress

[Daniel Martínez <da...@paradisosistemas.es>]

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.

Re: Workeffort Calendar Progress

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Workeffort Calendar Progress

[David E Jones <jo...@hotwaxmedia.com>]

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