Return-Path: 
 <dev-return-133699-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
X-Original-To: apmail-commons-dev-archive@www.apache.org
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 0E36F9EAF
	for <apmail-commons-dev-archive@www.apache.org>;
 Wed, 29 Feb 2012 18:25:59 +0000 (UTC)
Received: (qmail 32392 invoked by uid 500); 29 Feb 2012 18:25:58 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 32271 invoked by uid 500); 29 Feb 2012 18:25:58 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@commons.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@commons.apache.org>
List-Post: <mailto:dev@commons.apache.org>
List-Id: <dev.commons.apache.org>
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 32220 invoked by uid 99); 29 Feb 2012 18:25:58 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Feb 2012 18:25:58 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [85.13.144.143] (HELO dd25322.kasserver.com) (85.13.144.143)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Feb 2012 18:25:50 +0000
Received: from [192.168.2.101] (dslb-094-220-112-044.pools.arcor-ip.net
 [94.220.112.44])
	by dd25322.kasserver.com (Postfix) with ESMTPSA id 69CFD1DFA043
	for <dev@commons.apache.org>; Wed, 29 Feb 2012 19:25:29 +0100 (CET)
Message-ID: <4F4E6D96.7090907@systemoutprintln.de>
Date: Wed, 29 Feb 2012 19:25:26 +0100
From: Benedikt Ritter <bene@systemoutprintln.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [lang] Please fix DateParser Javadocs
References: 
 <CACZkXPwgs5eGhNS8yKecD16y_XMHJgU4_=QFeW61V_Qgzqr8qg@mail.gmail.com>
 <4F4E4E37.6090901@systemoutprintln.de>
 <CAOGo0VasVVnTc1SMANX-8taL0FQ-GB_vPF0ytH=WNmDRU7PZTw@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VasVVnTc1SMANX-8taL0FQ-GB_vPF0ytH=WNmDRU7PZTw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Am 29.02.2012 17:54, schrieb sebb:
> On 29 February 2012 16:11, Benedikt Ritter<bene@systemoutprintln.de>  wrote:
>> Am 29.02.2012 15:28, schrieb Gary Gregory:
>>
>>> Can someone please fix:
>>>
>>> [WARNING]
>>>
>>> C:\svn\org\apache\commons\trunks-proper\lang\src\main\java\org\apache\commons\lang3\time\DateParser.java:75:
>>> warning - Tag @link: can't find getTimeZo
>>> neOverridesCalendar() in org.apache.commons.lang3.time.DateParser
>>
>>
>> The problem is, that there is no method with name
>> "getTimeZoneOverridesCalendar()" in DateParser, so that link can't be
>> resolved (I think you already knew that :).
>> I suppose the comment is meant to refer to getTimeZone() in
>> java.util.Calendar.
>
> I don't think that's correct.
>
> The Javadoc originally said:
>
>       *<p>This zone is always used for<code>Date</code>  formatting.
>       * If a<code>Calendar</code>  is passed in to be formatted, the
>       * time zone on that may be used depending on
>       * {@link #getTimeZoneOverridesCalendar()}.</p>
>
> To me, this implies that there was/is a method called something like
>
> getTimeZoneOverridesCalendar()
>
> which was/is used to determine whether or not to use the timezone from
> the provided calendar.

You're right, maybe we have been a bit rash with fixing that. I've 
looked into the SVN log and there is no hint to where that comment was 
coming from. The interface was introduced in r1236055 with that comment. 
I've also looked into the corresponding issue LANG-462, but there is no 
clue as well.
Maybe Henri Yandell can give some hints, because he was involved in the 
discussion about that issue.

>
> Date.getTimeZone() just happens to be a similar method name; I don't
> see how it's relevant here.

As I said, Calendar.getTimeZone() was just my guess (because it said 
"OverridesCalendar").

>
> The way to find out is to check what the code actually does (did).

since DateParser is just an interface, there is no code to check ;-) So, 
what do we do now?

Regards,
Benedikt

>
>> If so, you can fix that by changing the link to: {@link
>> java.util.Calendar#getTimeZone()}
>>
>> Regards,
>> Benedikt
>>
>>
>>>
>>> It's not obvious to me what the right fix is.
>>>
>>> Thank you,
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org