Adrian: here is your chance to first understand, then be understood. If you'd like to propose an alternative based on what Andrew has written here, that's fine. Discounting it without discussion or discover, ie trying to understand, that's not so fine.
It seems like you didn't get my point from the last message, so maybe this will help to clarify...
-David On Oct 28, 2007, at 12:13 PM, Andrew Zeneski wrote:
Just my two cents here, I do not want everything to depend on a user selecting his timezone. There are many cases where we will no want to force this dependency. The main case being customer facing applications where the webmaster does not want to impose this requirement on their users.This was a requirement imposed on me and I see no reason why it wouldn't happen again. It is always common for webmasters to do all it takes to require less from their users.This was solved by obtaining the number of minutes from GMT offset in javascript (getTimezoneOffset()). Since we had no way to get a TimeZone string from javascript (only the number of minutes) the only way to do this was to pull the number of minutes and adjust the current time (which in this case, server time was GMT).The method I added to UtilDateTime was to help with this, but now I see it can be greatly improved. I think this method will be very useful. One thing which needs to change, is since the minutes offset is based on GMT, we need to make sure the Timestamp is set to GMT time, before the adjustment is made. This will give us a valid time in the user's timezone without a TimeZone object.I think it is good, to support the user selected TimeZone, but we should also look at methods which require this to be automated. In this case, no TimeZone object will be available in the session, but we can always get the number of minutes offset passed through from the browser.On Oct 27, 2007, at 4:19 PM, Adrian Crum wrote:Prior to the recent work done to bring user-selected time zones into the project, OFBiz pretty much ignored a user's time zone and locale and performed date/time calculations based upon the server's locale and time zone. This caused problems for international users - as the previous links point out.
smime.p7s
Description: S/MIME cryptographic signature
