I didn't delve too much into the details of your current approach, but couldn't you do this fairly easily using the Calendar class...
Date fromDb = ResultSet.getDate(...); Calendar cal = Calendar.getInstance(user's TimeZone, optionally user's Locale); cal.setTime(fromDb); Now you can manipulate/display the values in the user's timezone.... --- - Nayan Hajratwala - Chikli Consulting LLC - http://www.chikli.com -----Original Message----- From: Ryan Olson [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 2:23 PM To: Struts Users Mailing List Subject: [slightly OT] Time zone strategies 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>