On Mon, March 7, 2005 2:21 am, Henri Yandell said:
> Largely trying to avoid throwing it straight in as after many moons of
> failing, I'm making a push to get 2.1 out :)
I can certainly appreciate that :)
> 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.
To me, the part about mimicing the API makes some sense (so long as there
is an overload version that accepts a Calendar so that my use case is
handled too!). The part about extending math.Range (which I realize you
say you aren't sure about) I wouldn't like. It doesn't feel like it
really applies properly, a bit of a square peg in a round hole if you
will. I think the API is the part that really matters though.
I'm not entirely clear on why there are three parameters when constucting
the DateRange though... Seems like a range by definition should only
require two items, no? :)
> 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 :)
I can live with that :)
> We tend to make the target the first parameter btw, but that's no
> biggy. I also switched it to be a Date.
Also not a problem for me. However, I would think it would be better to
create another overloaded version to accept a Date rather than replacing
it. I still think there are cases where the base int-only version will
come in handy, and I'd hate to see if removed. I think all overloaded
versions callind on the int-only version is the most flexible model
anyway... I can't imagine an overloaded version I'd rally against :)
> 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.
Not a bad thought, but I would make an argument that as an application
developer, I'm not sure I'd be thrilled with having to use something other
than JDK standard classes (even though, to me anyway, its a bit bizarre in
the first place to have to use a Date or Calendar when I'm just dealing
with times). I suppose as long as it was easy to get a Time instance
based off of any of these, i.e., Time t = new Time(calendar); Time t = new
Time(date); ... and so on... then I'd be happy with that. I could see
using that myself.
> 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.
That's a good thought, I didn't think of doing it that way. Certainly, if
I could let the standard JDK classes handle the "conversion", then cool.
Plus, it should be able to handle just about any format one throws at it,
so that's certainly worth doing. In any case, I can't imagine it would
effect performance any more than the current implementation probably does
:)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
