Discussion: Time zones and software design

[Adrian Crum]

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.

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

[David E. Jones-2]

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

[Adrian Crum-2]

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 <[hidden email]> 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
>
>