Adrian, For now this strategy seems fine to me. I have to think more about it and especially to look at related code.
Besides, I promise to have a look, and hopefully commit, OFBIZ-642 tomorrow ;o) Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> > 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 >
