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
