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. 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 I'm not sure about any of these solutions, ie none of them stand out as the obvious answer. No matter what we do, we have to figure out a way to make this more consistent so that code all over doesn't need to worry about it. In other words, we do it in the UI layer as centrally as possible. We have a problem right now though where the code is spread all over and even if we go with something that automatically handles this for HTML output and HTTP input then we'd have to remove time zone handling everywhere else (lest the time zone compensation be done twice and we end up skewed the other way). For now, I guess I'm going with solution #1 since that is the direction the project is already moving in. -David
