Sorry to jump in mid-conversation, but I have recently written a
DateRange class of my own.
I think it would be much simpler to make the class only operate on Date
objects, both in the constructor:
DateRange(Date d1, Date d2)
and in the methods to check if dates fall within the range:
contains(Date)
intersects(Date)
I find this easier than dealing with numerous ints for startHour,
startMinutes, endHour, endMinutes.
But again, I'm not 100% sure of the requirements.
If what I've described sounds good, perhaps I could upload it into
Bugzilla. Let me know.
Frank W. Zammetti wrote:
> 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]
