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 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.
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. >> 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? -David
