David E Jones wrote:
On Feb 24, 2010, at 3:01 PM, Adrian Crum wrote:
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 relat
ive 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.
That's not correct. The Timestamp object has an internal representation that is
relative to GMT. Or, more to the point, the internal representation is just a
long that is relative to a certain point in time so time zone doesn't matter.
The problem comes into play when you want to convert it to or from a string
that consists of things like days and hours.
Exactly. Like I said: "The fundamental problem is there is no direct
relation of any given Timestamp to any TimeZone." You have to have
*both* to convert a Timestamp to a String.
You have a Timestamp instance in your hand and you need to convert it to
a String. What time zone do you use? Who knows? There isn't enough
information in the data type to do the conversion.
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.
And how do we pass this object in a URL parameter, or in a hidden HTML form
field?
The conversion framework will take care of that. It might be better to
think about application scenarios.
Scenario 1: A user types a date/time into a data entry field and clicks
Submit. The application's design specifies the date/time is referenced
to the user's time zone. So, the date/time string is combined with the
user's time zone in a LocalizedDate and that object is passed around the
framework. The framework code doesn't have to guess what time zone to
use for conversions - because the time zone is included in the
LocalizedDate.
Scenario 2: A Timestamp entity field needs to be displayed. The
application's design specifies the Timestamp is referenced to the
server's time zone. The Timestamp field is combined with the server's
time zone in a LocalizedDate and that object is passed around the
framework. The framework code doesn't have to guess what time zone to
use for conversions - because the time zone is included in the
LocalizedDate.
