Dates, Times, Internationalization, and the UtilDateTime class
Locked
Dates, Times, Internationalization, and the UtilDateTime class
 
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Adrian, first of all, I want to thank you for putting all of this information in one place. it's a great thing for people to be able to see your thought patterns and understand how all of this fits together.
Here are my pros and cons with what you're saying here: Pros: You are bettering the project with more consistent and reproduceable methods and procedures being put in. Cons: This removes backwards compatibility and for those of us that don't have one single application to keep track of - but instead have a large number - this can be a costly modification to make. So, what I'm saying here is that while I believe that the work that you are doing here is a great win for the project overall, I do not agree with breaking backwards compatibility to get there. Leave the other ones in place - deprecate them for all I care, but don't go around breaking things that aren't broken for other people. And no - I don't agree with your "leave no room for discussion" stance on if you don't go with what you're saying here you're against internationalization. What I do think is that if people decided not to use the methods that provide strong Locale and TimeZone dependence, then they open themselves up to running into issues that they could've avoided. This is not a new project and these things are not new concepts - they evolve and get better - but I see no reason to remove the other methods at this point - deprecate them, document them, and put the information explicitly in the Best Practices manual. Cheers, Tim -- Tim Ruppert HotWax Media o:801.649.6594 f:801.649.6595 On Oct 27, 2007, at 2:19 PM, Adrian Crum wrote:
|
smime.p7s (3K)
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
Administrator
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
Administrator
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
Administrator
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
Administrator
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
In reply to this post by Adrian Crum-2
Now that I've read this thread so far, all I can say is: well^H^H^H^Hwhy not^H^H^H^H^H^H^Hif we just^H^H^H^H^H^H^H^H^H^H. I guess I'm speechless. Maybe we should start over? Adrian: you might have better success stating your case in terms of objectives and not superlatives, without assigning motives to other peoples actions, and in general with the emotion taken down a few notches. In doing so, you might actually have the opportunity to do the most wide thing I have ever experienced: seek first to understand, then to be understood. That is generally more productive than appeals to authority and assigning motive (aka the blame game). This isn't that complex an issue, and probably the only reason it has escalated beyond 3-4 messages into a "holy war", as Jacopo put it, is a bit of failure to do the above. That that complex, just another day, it's happened before and it will happen again. All in all, not such a big deal once we don't take ourselves so seriously. Interesting that the "OFBiz Committers Roles and Responsibilities" document covers some of this same ground... and that has been there for a long time. -David On Oct 27, 2007, at 2:19 PM, Adrian Crum wrote: > I'm starting this thread in response to Jacques' suggestion that we > discuss date/time calculations, the UtilDateTime class, and whether > or not older methods in that class should be deprecated. > > Anyone wanting to follow along or participate in the discussion > should start off by visiting these links: > > http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html > http://www.icu-project.org/docs/papers/international_calendars_in_java.html > http://www-128.ibm.com/developerworks/java/library/j-i18n.html#N1019D > > 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. > > The source of the problem was the UtilDateTime class, and Vinay > Agarwal was the first developer to address the issue - https://issues.apache.org/jira/browse/OFBIZ-2 > . The UtilDateTime class was updated in June 2007 to support the use > of locales and time zones in date/time calculations. Soon afterwards > the framework was changed to accomodate a user-selected time zone - > the user's java.util.TimeZone object is now available in the service > context, the session, and in the screen rendering context. In > addition, the user's last time zone selection is persisted. > > Once all of the infrastructure was in place to support a user- > selected time zone, I worked on the Work Effort calendar to support > the new capability. That work was committed to the project in August > 2007. It's important for this discussion that the international > community visit this link: > > https://demo.hotwaxmedia.com/workeffort/control/month > > and spend some time experimenting with various time zones and > locales. This is important because the server is located in the > central US, and yet the calendar always presents date/time data > according to the user's locale and time zone selections. The Work > Effort calendar is a perfect demonstration of the concepts presented > by IBM and the java community. The success of this effort was due to > using only the newer methods in UtilDateTime, and eliminating all > calls to the older methods. > > With a successful working example of the new UtilDateTime methods, > the question comes up: Should we keep the older methods that ignore > the user's time zone and locale? My answer is No. As long as those > methods remain in the class, lazy developers will try to use them. A > perfect example is the commit in rev 586582 and the storm of > controversy that erupted from it. > > I submitted a patch to deprecate the UtilDateTime methods that > ignore the user's locale and time zone - https://issues.apache.org/jira/browse/OFBIZ-1361 > . That patch is being challenged based upon the notion that the > older methods will always be useful. I don't agree with that view. > Here's why: > > Now that we have the capability to better internationalize OFBiz, we > should make efforts to do so. All of OFBiz should make use of the > new UtilDateTime methods so that the user is presented with > consistent date/time data. There will be places in OFBiz that will > have exceptions - places where the server's locale and time zone are > preferred. Let's use the Webtools component for an example. If > Webtools is intended to display date/time data in the server's time > zone and locale, then that component can construct its own TimeZone > and Locale objects to be passed to the new methods. The bottom line > is, if the older methods didn't exist, there would still be ways to > achieve the same results. > > It has been suggested that, instead of deprecating the older > methods, they should have JavaDoc comments pointing out that they > shouldn't be used. Well, if they shouldn't be used, then why keep > them? > > To summarize: Deprecating the methods provides an incentive for > developers to stop using them. Backwards compatibility can be > achieved by supplying some form of default objects to the new methods. > > From my perspective, any argument in support of keeping the older > methods is an argument against internationalization. > > -Adrian > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com |
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Dang it must be late... too many typos so resending this: Now that I've read this thread so far, all I can say is: well^H^H^H^Hwhy not^H^H^H^H^H^H^Hif we just^H^H^H^H^H^H^H^H^H^H. I guess I'm speechless. Maybe we should start over? Adrian: you might have better success stating your case in terms of objectives and not superlatives, without assigning motives to other peoples actions, and in general with the emotion taken down a few notches. In doing so, you might actually have the opportunity to do the most wise thing I have ever experienced: seek first to understand, then to be understood. That is generally more productive than appeals to authority and assigning motive (aka the blame game). This isn't that complex an issue, and probably the only reason it has escalated beyond 3-4 messages into a "holy war", as Jacopo put it, is a bit of failure to do the above. Not that complex, just another day, it's happened before and it will happen again. All in all, not such a big deal once we don't take ourselves so seriously (as with most thigs). Interesting that the "OFBiz Committers Roles and Responsibilities" document covers some of this same ground... and that has been there for a long time. -David On Oct 28, 2007, at 4:42 AM, David E Jones wrote: > > Now that I've read this thread so far, all I can say is: > well^H^H^H^Hwhy not^H^H^H^H^H^H^Hif we just^H^H^H^H^H^H^H^H^H^H. > > I guess I'm speechless. > > Maybe we should start over? > > Adrian: you might have better success stating your case in terms of > objectives and not superlatives, without assigning motives to other > peoples actions, and in general with the emotion taken down a few > notches. > > In doing so, you might actually have the opportunity to do the most > wide thing I have ever experienced: seek first to understand, then > to be understood. That is generally more productive than appeals to > authority and assigning motive (aka the blame game). > > This isn't that complex an issue, and probably the only reason it > has escalated beyond 3-4 messages into a "holy war", as Jacopo put > it, is a bit of failure to do the above. That that complex, just > another day, it's happened before and it will happen again. All in > all, not such a big deal once we don't take ourselves so seriously. > Interesting that the "OFBiz Committers Roles and Responsibilities" > document covers some of this same ground... and that has been there > for a long time. > > -David > > > On Oct 27, 2007, at 2:19 PM, Adrian Crum wrote: > >> I'm starting this thread in response to Jacques' suggestion that we >> discuss date/time calculations, the UtilDateTime class, and whether >> or not older methods in that class should be deprecated. >> >> Anyone wanting to follow along or participate in the discussion >> should start off by visiting these links: >> >> http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html >> http://www.icu-project.org/docs/papers/international_calendars_in_java.html >> http://www-128.ibm.com/developerworks/java/library/j-i18n.html#N1019D >> >> 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. >> >> The source of the problem was the UtilDateTime class, and Vinay >> Agarwal was the first developer to address the issue - https://issues.apache.org/jira/browse/OFBIZ-2 >> . The UtilDateTime class was updated in June 2007 to support the >> use of locales and time zones in date/time calculations. Soon >> afterwards the framework was changed to accomodate a user-selected >> time zone - the user's java.util.TimeZone object is now available >> in the service context, the session, and in the screen rendering >> context. In addition, the user's last time zone selection is >> persisted. >> >> Once all of the infrastructure was in place to support a user- >> selected time zone, I worked on the Work Effort calendar to support >> the new capability. That work was committed to the project in >> August 2007. It's important for this discussion that the >> international community visit this link: >> >> https://demo.hotwaxmedia.com/workeffort/control/month >> >> and spend some time experimenting with various time zones and >> locales. This is important because the server is located in the >> central US, and yet the calendar always presents date/time data >> according to the user's locale and time zone selections. The Work >> Effort calendar is a perfect demonstration of the concepts >> presented by IBM and the java community. The success of this effort >> was due to using only the newer methods in UtilDateTime, and >> eliminating all calls to the older methods. >> >> With a successful working example of the new UtilDateTime methods, >> the question comes up: Should we keep the older methods that ignore >> the user's time zone and locale? My answer is No. As long as those >> methods remain in the class, lazy developers will try to use them. >> A perfect example is the commit in rev 586582 and the storm of >> controversy that erupted from it. >> >> I submitted a patch to deprecate the UtilDateTime methods that >> ignore the user's locale and time zone - https://issues.apache.org/jira/browse/OFBIZ-1361 >> . That patch is being challenged based upon the notion that the >> older methods will always be useful. I don't agree with that view. >> Here's why: >> >> Now that we have the capability to better internationalize OFBiz, >> we should make efforts to do so. All of OFBiz should make use of >> the new UtilDateTime methods so that the user is presented with >> consistent date/time data. There will be places in OFBiz that will >> have exceptions - places where the server's locale and time zone >> are preferred. Let's use the Webtools component for an example. If >> Webtools is intended to display date/time data in the server's time >> zone and locale, then that component can construct its own TimeZone >> and Locale objects to be passed to the new methods. The bottom line >> is, if the older methods didn't exist, there would still be ways to >> achieve the same results. >> >> It has been suggested that, instead of deprecating the older >> methods, they should have JavaDoc comments pointing out that they >> shouldn't be used. Well, if they shouldn't be used, then why keep >> them? >> >> To summarize: Deprecating the methods provides an incentive for >> developers to stop using them. Backwards compatibility can be >> achieved by supplying some form of default objects to the new >> methods. >> >> From my perspective, any argument in support of keeping the older >> methods is an argument against internationalization. >> >> -Adrian >> >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com > |
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
Administrator
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
In reply to this post by Adrian Crum-2
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. |
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
In reply to this post by Andrew Zeneski-2
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. > |
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
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 <[hidden email]> 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. |
Re: Dates, Times, Internationalization, and the UtilDateTime class
|
|
| Free forum by Nabble | Edit this page |