Michael,
Yes, Daylight Saving Time is accomodated. The utility methods mentioned in step #3 use the
java.util.TimeZone and java.util.Calendar classes - which handle all of the messy calendar and time
keeping details.
Try out the we_svc_bsh_ftl.patch patch in OFBIZ-1089
(https://issues.apache.org/jira/browse/OFBIZ-1089). You'll see the strategy I proposed being used in
the Workeffort Calendar.
-Adrian
Michael Jensen wrote:
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
