Out of curiosity, would this new strategy also take into account Daylight Savings time? Being an inexperienced java programmer, I'm not sure if this is built into java.util.TimeZone already or if it would have to be built into ofbiz.
Mike Adrian Crum wrote: > 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 > -- Millcreek Systems, Inc. P.O. Box 9835 Salt Lake City, Utah 84109 Phone: 801.649.4903 Skype: millcreeksys (http://millcreeksys.com/skype/)
