David, A number of developers have replied to this thread with their thoughts on the subject of the thread. You keep commenting on the author of the thread.
What I'm interested in is your thoughts on the subject. All of this other dialog is pointless. In case you missed the subject of this thread, I'll restate it: Now that the UtilDateTime class has methods that support internationalization, should we continue to use the methods that ignore a user's locale and time zone, or should we deprecate them? Let's try to stay focused on the project and the subject at hand. -Adrian David E Jones <[EMAIL PROTECTED]> wrote: 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. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
