On Sun, 06 Mar 2005 23:22:57 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Thanks for the comments Henri! I did see those comments. Rather than
> reply on the ticket, I thought here might be more appropriate.
>
> I don't think I can really comment on the idea of it being a tiny bit of
> something larger. You may be 100% right, and this functionality would
> be rolled into that, but I do think this comes up for people enough that
> it might be nice to have sooner rather than later, even if with the
> understanding that down the road it will be expanded greatly.
Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)
On the larger ideas (DateRange class), I'd imagine an API of:
// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }
Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.
> I did find your concern about ints interesting though, and I wanted to
> explain my rationale for that... Very simply, I think the most common
> usage of this type of function will result from wanting to know if a
> given Calendar object's time falls within a given range. Since the
> Calendar's get method returns an int, it seems logical to me. In
> addition, I think a simple (relatively simple anyway) comparison of ints
> is the easiest way to accomplish this function. I would be interested
> to know how you would envision it being done with something other than ints.
Given the criteria above, at least an API of:
DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)
It's the 2,358 number I dislike :)
We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.
Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.
The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.
> On the servlet thing... I originally mentioned these additions probably
> three months ago. The same thing basically was said about the status of
> the project as what you said. It was mentioned (I forget by who
> frankly) that submitting these could be the impetuous for getting a
> first release out the door. That might be a little too hopeful frankly,
> but it couldn't hurt, as you kind of say :)
Might even have been me that said it :(
Will take a look tomorrow.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
