> > 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
The server has no time zone. It's all the user's timezone(and locale, really). The server should always deal with values that don't carry any explicit timezone/locale/color/size constraints. Those are purely needed for front-end representation. This would mean that entity xml data has to encode the internal timestamp value, or a string version that includes a timezone. It should throw an exception if there is no timezone when converting from a String. Maybe introduce a new object, UserStringValue, that contains a String, and whatever other identifying information is required. Then, the conversion system could convert that to Timestamp, Date, currency, etc.
