I wouldn't look at doing anything this weekend, there will probably be arguments against deprecation as well, best to wait for those to be heard.
Scott On 28/10/2007, Jacques Le Roux <[EMAIL PROTECTED]> wrote: > Tim, Adrian, all, > > Thanks to Adrian, things are much more clear now and nobody (reading this ML) > can argue that he/her was not aware. > > It seems that we got common ground now. I'm quite happy with that. I can help > to document and deprecate (which does not mean remove) if needed... > > It should be noted that even in Java very old deprecated method still stands. > Backwards compatibility is something we can't seriously ignore. > > Jacques > > De : "Adrian Crum" <[EMAIL PROTECTED]> > > Tim Ruppert <[EMAIL PROTECTED]> wrote: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. > > > > > > I agree with you here. I should have worded that sentence better - "From my > > perspective, any argument against deprecating the older methods is an > > argument against internationalization." > > > > I'm all for making this a gradual transition. That sentence was intended to > > address the notion that the older methods will always be useful. > > > > -Adrian > ----- Message d'origine ----- > De : Tim Ruppert > À : [email protected] > Envoyé : samedi 27 octobre 2007 22:44 > Objet : 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 > http://www.hotwaxmedia.com > > > o:801.649.6594 > f:801.649.6595 > > > > > 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 > >
