Actually, having the popup calendar use the user-selected time zone will not be
sufficient. The popup calendar must support a selectable time zone.
Here is an example based on the current code:
A user is in Los Angeles and they have their time zone set to Pacific/Los
Angeles. They are using an instance of OFBiz that is hosted on a server based
in Salt Lake City. The user wants to schedule a Friday 3PM event in New York
City using the Work Effort application. How does the user do that?
When they enter the estimated start time, what time zone is that start time in
- Los Angeles, Salt Lake City, or New York? There is no way to know for sure.
In the current code, work efforts default to the user's time zone. So the user
would have to know that, and then do a manual computation to enter the correct
New York event time. Other applications that use date/time fields are not that
well defined or not that well known.
So, the popup calendar needs to give the user the ability to select a date/time
AND a time zone. Cool so far.
But now OFBiz needs to know what to do with that information. Right now
date/time values are converted to Timestamps. How does the time zone the user
selected in the popup calendar travel with that Timestamp? It doesn't. As the
Timestamp passes through various framework artifacts. it might be converted to
a String and back using the server's time zone or the user's preferred time
zone - depending on the code. There is a good chance that the Timestamp value
will get altered along the way - as you found out.
We could come up with a rule that all framework code use X time zone for
conversions, but then we rely on all members of the developer community to
follow that rule. Good luck with that.
That's why we need a date/time data type that includes time zone information.
Anywhere along the execution path, the data type can be converted to/from other
data types and retain its original intended value.
-Adrian
--- On Tue, 3/30/10, David E Jones <d...@me.com> wrote:
> 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
>
>
