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. Does anyone know the best way to workaround/fix this problem? Maybe another suffix for the forms with the type of the field? 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 >
