First of all thanks to Adrian for his work on this area and for the passion.
I think it would greatly help if someone, maybe Adrian? :-), could post
a short message to the user list with a few small instructions for
transitioning external components to the new methods; something like this:
"if, after an upgrade, you get an error like this [...] in your custom
component, then you can fix it in the following way:
bsh: modify the UtilDateTime.adjustTimestamp(timestamp) to
UtilDateTime.adjustTimestamp(timestamp, timeZone, locale)
ftl: etc..."
Then, we can remove/deprecate/comment/uncomment/revert that new small
method... I'll let the decision to you all: I had an opinion on this,
but I had it when it was still a small issue (no OFBiz standard
application was using it)... now that it is grown to an holy war I'll do
what I can to stay out of it :-)
Jacopo
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
