Hi all,

Although this problem isn't necessarily unique to struts, it's certainly 
something that many of you may have come across in building struts 
applications. I'm writing a CRUD-type app to manage news articles which will 
support users in various time zones. Individual articles have date/time 
stamps which are normalized to the server reference timezone as they are 
stored in the model layer. However, each user should see and modify the dates 
in his/her own timezone on the presentation layer, optionally specifying 
alternate timezones if desired.

My current approach is the following (bear with me):

- business layer object ArticleBO contains a Date field populated from db with 
ResultSet.getDate()
- view layer ActionForm ArticleForm contains a Date object (internalDate) as 
well as String fields for date and time; internalDate is prepopulated from 
ArticleBO for view/edit actions
- Article JSP contains two text fields for date and time strings, which are 
not themselves prepopulated from the ArticleForm, but rather filled in as the 
page loads via JavaScripts which use internalDate.getTime() to create a 
localized JavaScript Date object and corresponding date/time strings for the 
form
- ArticleForm also contains a hidden field clientTimezoneOffset that is 
populated by JavaScript as (new Date()).getTimezoneOffset(), which is the 
client's GMT offset in minutes
- ArticleForm returns to my add/edit/whatever Action after validation, at 
which point the date/time strings are converted back to a Date object using a 
SimpleDateFormat. The SimpleDateFormat is set to the client's timezone using 
the offset information in the clientTimezoneOffset field. This is tricky 
because 
1. JavaScript-supplied values are the negative of what Java expects -- for 
example, California comes out as +8 (+7 DST) instead of -0800 (-0700 DST)
2. Since the offset value is adjusted for DST according to the local time on 
the client, the retrieval method must un-adjust it accordingly when setting 
the raw offset of the resulting TimeZone (which is DST-neutral)
- ArticleBO populated from ArticleForm now holds a Date object in the server's 
timezone

It took me awhile to figure that all out, and it seems to work well based on 
the testing I've done by setting the test lab machines' clocks/timezones 
every which way. It's an awfully convoluted process, though, and I don't like 
to rely on JavaScript. 

Has anyone else come up with a better solution? 

Thanks

Ryan Olson


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to