On Feb 24, 2010, at 3:00 PM, Adam Heath wrote:
>>
>> 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.
The server has not time zone? Then how does it decide on the internal
representation for the following:
Timestamp.valueOf("2010-02-23 12:00:00.000");
That's just a date and time with no time zone... how does it figure out how
many milliseconds are between that date/time and the epoch time point (January
1, 1970, 00:00:00 GMT)?
I'll restate the assertion that any running JVM has a default time zone
setting. For an example check out the TimeZone.getDefault() method.
> 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.
A new object won't help. The Timestamp object is just fine. The problem is in
converting to/from String representations of the date/time.
Yes, a string representation that always includes a time zone is an interesting
idea (which part of my #2 possible solution). We would still need to support
the case where we want to allow the user to manually enter a time or date/time
without explicitly saying what the time zone is, but for URL parameters and
hidden form fields that have values generated by the system this would be fine.
-David
