David E Jones wrote:
On Feb 24, 2010, at 1:15 PM, Adrian Crum wrote:
David E Jones wrote:
I'm wondering though: how many more places are not handling the time zone
correctly? Is there a better way to manage things when the user's time zone
setting is different from the server's? Right now it's a mess...
This will be a worthwhile discussion - because handling time zones correctly
hasn't been discussed before. First off: What does handling them correctly mean?
Right now, the process is to try to use the user's time zone if it is
available, otherwise use the default. There is no strategy or enforcement of a
set of rules - so it isn't surprising that there are inconsistencies.
I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default.
In other words, these String representations of Timestamps passed through the
browser need to be interpreted consistently because they do not carry time zone
information with them (ie they are not like the Timestamp internal
representation which is a relative time from a constant point in time, in the
GMT time zone so there is no confusion).
So, we have consistency problems on two sides:
1. producing timestamp Strings for users to, or for the browser to pass back to
the system in a URL parameter or hidden field
2. interpreting timestamp Strings in HTTP requests, from form fields or URL
parameters
On both sides we have issues where changing between String value and Timestamp
object may be done in the server's time zone or the user's time zone.
It would be nice if all of the code that produced the Strings or consumed them
was consistent, but it is spread all over and not consistent.
Plus, how do you specify a time zone and where? What if you have
multi-tenancy running on a single OFBiz instance and each tenant (or
store) wants to appear to be in a different time zone? That's even more
complicated than server versus user time zones.
The fundamental problem is there is no direct relation of any given
Timestamp to any TimeZone.
So, how to fix it:
1. more testing where the user's time zone is different from the server's, and
fix one problem at a time
2. try to introduce some sort of time zone value in timestamp String
representations so that we know what the time zone is instead of trying to stay
consistent with either the user's time zone or the server's
3. refactor all Timestamp code deal with #1 or #2 above to go through a single
spot and do the time zone compensation consistently
4. Use stronger typing. Create a LocalizedDate class and pass that
around instead of a plain Date or Timestamp. Then it will be clear what
the intention is. A plain Timestamp would imply the server's time zone.
-Adrian
