Adrian,
I stated my opinion in the Jira issue originally. It has not changed. I've just been trying to referee since then, and trying to call out unproductive approaches to settling on this issue.
My opinion is still the same: the framework is NOT a 4GL with strict ways of doing things, we want to have best practices and flexibility that does not force a certain way of doing things. We do this for both utility and humility. That means it's easier for people to mess up here and there, but it also means that when something weird comes up it's not a lot of work to handle it. As for designing the tools in the framework, that comes from doing it manually and trying different things a lot before designing and building a tool. That goes for all of the framework. The saying "hindsight is 20/20" is particularly applicable... patterns emerge from trying a lot of stuff, and then cleaning things up when the picture is better understood.
In this particular case to me that general principle is applied like this: leave the method and put your efforts into documenting best practices instead of fighting out other people's work.
-David On Oct 28, 2007, at 8:57 PM, Adrian Crum wrote:
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.
smime.p7s
Description: S/MIME cryptographic signature
