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
