On Mar 30, 2010, at 4:01 PM, Adrian Crum wrote: > A short while back, it was mentioned that the time zone handling in OFBiz is > inconsistent. I suggested that a date-time data type should be used instead > of a java.util.Date or java.sql.Timestamp. Before a change like that can be > made, we really need to discuss time zones on a higher level - the business > logic level.
I'm not aware of any problems with the use of the Timestamp object... it's the conversion to String (without the time zone characters) or taking a String from the user with an implied time zone that is the issue. At the minute I'm not aware of any more issues with this, but of course that doesn't mean there aren't any. Actually, there is still the issue of the popup calendar using the client's browser time zone and not the time zone the user has specified in the application, but that's just an issue with the calendar popup and not the server side part of the code. -David > In our current code, a Timestamp is passed around the framework and within > applications without an associated time zone. Each bit of code that "touches" > the Timestamp has to assume which time zone to use. [The Timstamp's value is > referenced to GMT, but some places in code need to convert it to a time zone > other than GMT for the purpose of display or object-type conversion.] > Sometimes the server's default time zone is used and sometimes the > user-selected time zone is used. Looking through the code, there doesn't seem > to be a business logic reason for the choice. Instead, it seems to be more > like "If the user-selected time zone is available, use that - otherwise use > the default." That is the crux of the inconsistency. > > If we can define a set of rules for which time zone to use, then it will be a > simple matter to go through the code and eliminate a lot of the inconsistency. > > I can think of three rules off the top of my head. I'm sure there are more, > and everyone is welcome to add to the list. > > 1. Automatic server processes like the Job Scheduler should use the server's > time zone. > > 2. Customer-facing processes should use a product store's time zone. Example: > "Your order will be shipped by 4:30 PM PST today." > > 3. Calendar applications (anything work effort related) should use the > user-selected time zone. > > Once a set of time zone rules are defined and agreed upon, we can create a > Wiki page for them. Then we can compare our code to the rules and fix the > inconsistencies. > > What do you think? > > -Adrian
