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