[lang] DateUtils

[Henri Yandell <ba...@generationjava.com>]

Okay, code pushed in. Couple of things:

1) Use [lang] in emails to discuss things. Stops the other Commons
developers from murdering us in our sleep.

2) The Tests need to hook into LangTestSuite in the same direction and
have a suite() and main(String[]) methods. I've modified DateUtilsTest to
fit these.

In other news:

CalendarUtils needs to move from the sandbox over to the main line. I'll
begin by simply doing the move, but it and DateUtils need to get on the
same page and figure out how they link.

DateUtils.getMoonPhase seems a little obscure :)

My suggestion is that someone go through each class, collate the methods
in each one and send those methods through to the list. Include a
suggestion on whether CalendarUtils and DateUtils should be the same class
and which methods should be killed.

Anyone up for this?

Hen

On Mon, 16 Dec 2002, Henri Yandell wrote:

>
>
> On Mon, 16 Dec 2002, Sean Schofield wrote:
>
> > This is the plan.  Can we go ahead and add the new version of DateUtils now?
>
> Go for it. Just push the zip/patch up to the list.
>
> Hen
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Ch...@dlr.de]

If my time allows I will take a ditch on it. I will search for
some examples to see if someone has taken the right approach,
otherwise I will take the SimpleDateFormat APIdoc specification
and start from there. But my time scale for this would be at
present about a month... Anyone out there with the same itch
but more urgent?

Is there someone that believes we should use javacc or antlr
grammars for the format string? Or should I write a hand parser
(I've done this many times before) to do the parsing and
formatting?

We should include several format strings for the standards
(ISO, IEEE, some RFCs, etc.). The JDK classes could still
be used for the locale specific formating.

Is this fine?

-- 
:) Christoph Reck

Sean Schofield wrote:
>>
>>
>>> 3) createDateFormat( ) should return our new thread-safe DateFormat 
>>> (maybe this will be an inner class for now?)
>>
>> +1
> 
> 
> Christoph,
> 
> Earlier you expressed interest in taking the lead on the new 
> SimpleDateFormat.  Do you want to go ahead with that?  If so, lets 
> square away the details (class name, package, etc.)  Also, you may want 
> to check with Stephen who had mentioned he be willing to help.
> 
> - sean
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

>
>
>> 3) createDateFormat( ) should return our new thread-safe DateFormat 
>> (maybe this will be an inner class for now?)
>
>
> +1

Christoph,

Earlier you expressed interest in taking the lead on the new 
SimpleDateFormat.  Do you want to go ahead with that?  If so, lets 
square away the details (class name, package, etc.)  Also, you may want 
to check with Stephen who had mentioned he be willing to help.

- sean



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Ch...@dlr.de]

Sean Schofield wrote:
> Still haven't had a chance to review CalendarUtils.  In the meantime, 
> here are my thoughts on the existing DateUtils methods:
> 
> 1) Eliminate getPhaseOfMoon( ) as has already been suggested.  (I wonder 
> how the Ant guys were planning on using that)  ;-)
> 

A stated elsewhere in this thread... this is more for a CalendarUtil for
non gregorian calendars...

> 2) Rename getDateForHeader( ) to getSmtpDate( ) or something more 
> descriptive.

I remember seeing that the HTTP (and SMTP) RFCs state a specific IEEE
standard for the date string format.

So I believe we should either have static helpers like formatISO8601(Date)
or even format(Date, String) with the String being the ISO, RFC or IEEE
standards (similar to the i8n string/stream utlities).

>
> 3) createDateFormat( ) should return our new thread-safe DateFormat 
> (maybe this will be an inner class for now?)

+1

> 
> Also, TestCalendarUtils is using deprecated version of Date constructor. 
> We can fix those once we decide what we're going to do with CalendarUtils.
> 
> What are other peoples thoughts on this and on CalendarUtils?
> 
> - sean

-- 
:) Christoph Reck


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Stefan Bodewig <bo...@apache.org>]

On Tue, 17 Dec 2002, Sean Schofield <ne...@schof.com> wrote:

> 1) Eliminate getPhaseOfMoon( ) as has already been suggested.  (I
> wonder how the Ant guys were planning on using that)  ;-)

I wanted a specific deprecation warning to say that using a certain
attribute would cause behaviour that depended on the phase of the moon
and then print different log messages after that.  It was voted down
but the method has been kept.

> 2) Rename getDateForHeader( ) to getSmtpDate( ) or something more
> descriptive.

It's the same format HTTP, NNTP and others would use IIRC.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Henri Yandell <ba...@generationjava.com>]

On Tue, 17 Dec 2002, Sean Schofield wrote:

> >
> >
> >>>To be honest, I'm not convinced we need two classes. DateUtils so far
> >>>looks like DateFormatUtils to me. If those methods were kept, they do make
> >>>more sense in CalendarUtils.
> >>>
> >>>Hen
> >>>
> >>>
> >>>
> >>What's DateFormatUtils?  Is this a proposed class or something that
> >>already exists?
> >>
> >>
> >
> >My fault. I meant, it seems concerned with DateFormats and not Dates.
> >
> >Hen
> >
> >
> Hen,
>
> Still a bit confused.  Are you saying that DateUtils (as it stands now
> in CVS) might be more appropriately named DateFormatUtils?  Or that it
> resembles java.text.DateFormat?

The former. I see very little in there [phase of moon aside] that isn't
really a wrapper around the DateFormat concept.

In fact, we should be suspicious of a DateUtils as java.util.Date is
really just a milli-second-based instant in time.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

>
>
>>>To be honest, I'm not convinced we need two classes. DateUtils so far
>>>looks like DateFormatUtils to me. If those methods were kept, they do make
>>>more sense in CalendarUtils.
>>>
>>>Hen
>>>
>>>      
>>>
>>What's DateFormatUtils?  Is this a proposed class or something that
>>already exists?
>>    
>>
>
>My fault. I meant, it seems concerned with DateFormats and not Dates.
>
>Hen
>  
>
Hen,

Still a bit confused.  Are you saying that DateUtils (as it stands now 
in CVS) might be more appropriately named DateFormatUtils?  Or that it 
resembles java.text.DateFormat?

- sean



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Henri Yandell <ba...@generationjava.com>]

On Tue, 17 Dec 2002, Sean Schofield wrote:

> >
> >
> >To be honest, I'm not convinced we need two classes. DateUtils so far
> >looks like DateFormatUtils to me. If those methods were kept, they do make
> >more sense in CalendarUtils.
> >
> >Hen
> >
> What's DateFormatUtils?  Is this a proposed class or something that
> already exists?

My fault. I meant, it seems concerned with DateFormats and not Dates.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

>
>
>To be honest, I'm not convinced we need two classes. DateUtils so far
>looks like DateFormatUtils to me. If those methods were kept, they do make
>more sense in CalendarUtils.
>
>Hen
>
What's DateFormatUtils?  Is this a proposed class or something that 
already exists?

- sean





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Henri Yandell <ba...@generationjava.com>]

On Tue, 17 Dec 2002, Sean Schofield wrote:

> >Maybe we're being a bit too gregorianised. Let's make sure we discuss them
> >with the Ant guys before writing em off.
> >
> >
> What about the idea that was mentioned earlier about moving this to
> CalendarUtils?
>

To be honest, I'm not convinced we need two classes. DateUtils so far
looks like DateFormatUtils to me. If those methods were kept, they do make
more sense in CalendarUtils.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

>
>
>Sounds good.
>
>Maybe we're being a bit too gregorianised. Let's make sure we discuss them
>with the Ant guys before writing em off.
>
>Hen
>  
>
What about the idea that was mentioned earlier about moving this to 
CalendarUtils?

- sean


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Henri Yandell <ba...@generationjava.com>]

Sounds good.

Maybe we're being a bit too gregorianised. Let's make sure we discuss them
with the Ant guys before writing em off.

Hen

On Tue, 17 Dec 2002, [ISO-8859-1] Mat�as Giovannini wrote:

> Isn't it needed for use in lunar calendars (arabic, hebrew)?
>
> On Tuesday, December 17, 2002, at 12:18 PM, Sean Schofield wrote:
>
> > Still haven't had a chance to review CalendarUtils.  In the meantime,
> > here are my thoughts on the existing DateUtils methods:
> >
> > 1) Eliminate getPhaseOfMoon( ) as has already been suggested.  (I
> > wonder how the Ant guys were planning on using that)  ;-)
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Matías Giovannini <ma...@k-bell.com>]

Isn't it needed for use in lunar calendars (arabic, hebrew)?

On Tuesday, December 17, 2002, at 12:18 PM, Sean Schofield wrote:

> Still haven't had a chance to review CalendarUtils.  In the meantime, 
> here are my thoughts on the existing DateUtils methods:
>
> 1) Eliminate getPhaseOfMoon( ) as has already been suggested.  (I 
> wonder how the Ant guys were planning on using that)  ;-)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

Still haven't had a chance to review CalendarUtils.  In the meantime, 
here are my thoughts on the existing DateUtils methods:

1) Eliminate getPhaseOfMoon( ) as has already been suggested.  (I wonder 
how the Ant guys were planning on using that)  ;-)

2) Rename getDateForHeader( ) to getSmtpDate( ) or something more 
descriptive.

3) createDateFormat( ) should return our new thread-safe DateFormat 
(maybe this will be an inner class for now?)

Also, TestCalendarUtils is using deprecated version of Date constructor. 
 We can fix those once we decide what we're going to do with CalendarUtils.

What are other peoples thoughts on this and on CalendarUtils?

- sean


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] DateUtils

[Sean Schofield <ne...@schof.com>]

>
>
>1) Use [lang] in emails to discuss things. Stops the other Commons
>developers from murdering us in our sleep.
>  
>
Weren't we doing this already?  I'm confused ...

>CalendarUtils needs to move from the sandbox over to the main line. I'll
>begin by simply doing the move, but it and DateUtils need to get on the
>same page and figure out how they link.
>  
>
>DateUtils.getMoonPhase seems a little obscure :)
>  
>
I agree.  Its a cool function but probably not one many developers will 
need - unlike DateUtils.getHighTide :-)

>My suggestion is that someone go through each class, collate the methods
>in each one and send those methods through to the list. Include a
>suggestion on whether CalendarUtils and DateUtils should be the same class
>and which methods should be killed.
>
>Anyone up for this?
>
>Hen
>
>  
>
I'm willing to help out on this.  Give me some time to review 
CalendarUtils.  My instict tells me that this is really distinct from 
the DateUtils stuff.  The iterator stuff looks interesting but I have 
some concerns about the internationalziation.  I will report back 
shortly with my review.

Thanks again Hen for helping us to get started here.

- sean


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>