My feeling is that this would lead to confusion... The code I proposed is specifically for checking TIME ranges, but looking at your suggestion, I can't tell if it would work in determing if an hour fell within a given range. It might, but I can't tell from what you've posted here. It also, in my particular use case, has to work when the range start time is on a Monday and the range end time is on a Tuesday.
I think the object to ints that you and also Henri I think talked about is valid, but note that you only supply a single int for range start and end, you don't specify hours and minutes separately. It is this way because that's exactly what you get if you do Calendar.get(Calendar.HOUR_OF_DAY;. Henri already talked about adding a version to accept a Date, which I think makes sense, as long as its an overloaded version, I certainly have no objection. Now, all that being said, I for one say post your class if something like it doesn't already exist. Being able to determine if a date falls within a given range is also a valuable function for sure. :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, March 8, 2005 10:15 am, matthew.hawthorne said: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
