Daniel,
Daniel Martínez wrote:
I am right now developing support for locale formats in a local ofbiz
copy. I know this thread is not for this, but the steps (as Adrian put
them) for it are very similar to Timezones'
I have encountered a problem with performFind-style forms/services for
timezones and date format to be implemented.
Normally, a receiver from a form will be a service or a method (java,
bsh...). A service will convert the date correctly to the server
timezone by means of simpleTypeConvert() while another method (like
ShoppingCart's methods) will have to be modified to convert the dates.
But performFind does not have knowledge of the type of the fields. It
just looks for the suffixes and creates an SQL statement accordingly.
There is no way to know if there is a date in the "inputFields" list.
I think you are right; there is currently another issue about the
formatting of numbers with decimals affecting the performFind service:
https://issues.apache.org/jira/browse/OFBIZ-221
Does anyone know the best way to workaround/fix this problem? Maybe
another suffix for the forms with the type of the field?
Or two new input parameters: local and timezone of the incoming data
Adrian, nothing to comment about your planning, I think it is right.
Thanks,
--
Daniel
Adrian Crum escribió:
I'm starting a new thread for us to discuss the User-Selected Time
Zone Support strategy. The previous thread regarding the Workeffort
Calendar Progress started to expand into other subjects and strayed
away from the original subject, so I thought it would be best if we
separated the Time Zone support discussion into its own thread.
My hope is that we can use this thread to brainstorm and come up with
a general implementation strategy and maybe even assume/assign tasks
to achieve the end result.
*** The Goal: To have OFBiz support a user-selected time zone. Once a
user has selected a time zone, nearly all of the date/time data will
be displayed/entered referenced to that time zone. Some system
date/time data may be excluded from this goal.
In the Workeffort Calendar thread, there was some discussion about how
the date/time data should be formatted. I propose we leave that detail
out of this discussion so that we don't get diverted. How the
date/time data is formatted doesn't affect this thread's goal or its
strategy.
*** The Strategy (Some of this has been implemented already - it is
included here to make sure we're all on the same page) :
1. Provide a means for the user to select a time zone.
2. Persist the user's time zone selection and make a corresponding
java.util.TimeZone object generally available
3. Provide a set of utility methods that take the user's TimeZone
object as a parameter to perform date/time conversions, date/time
arithmetic, etc.
4. Modify some of the low-level framework code to accept an optional
TimeZone object, then pass that object on to the utility methods
mentioned in #3. A typical example would be the simpleTypeConvert(...)
method in ObjectType.java - where it handles Timestamp conversions.
5. Modify the higher-level code to call the low-level code using the
user's TimeZone object. Replace embedded date/time
conversions/arithmetic with utility method calls.
Please feel free to comment on/add to the stragey items.
Steps #1 and #2 have been implemented recently. (Btw, the patch in
OFBIZ-1126 needs to be committed to fix a bug).
Step #3 is partially implemented in the recent changes to
UtilDateTime.java.
Step #4 has not started yet. This step requires the expertise of
developers who are skilled with the service engine, widgets, and such.
Step #5 is the crucial one. Every step prior to this one will be
backwards compatible. Step #5 is the "plunge forward" - we do it all
or not at all.
I'm thinking we can start off by discussing and improving upon this
general strategy, then move on to specific tasks, etc. Let's hold off
on starting Jira issues, etc until the community has had time to
comment and reach a consensus.
Comments are encouraged and welcome.
-Adrian
