On Tue, March 8, 2005 3:45 pm, matthew.hawthorne said:
> I'm fairly sure that it would.
>
> My 'contains' method looks something like this:
> public boolean contains(Date d) {
> return this.startDate.before(d) && this.endDate.after(d);
As long as before() and after() are inclusive, then logically at least I
agree, that should work.
> I can't claim that I completely follow you here -- but I think I get the
> fundamental point.
That's OK, I don't follow *myself* half the time :)
> I can appreciate your desire to only provide hours and minutes, if that
> is all that you care about. Part of the problem is that Java only deals
> with dates in the full context: year, month, day, hour, seconds, etc.
> So, stripping some of that information away may make the calculations a
> bit trickier.
To me it makes it *easier*... The original use case that caused me to
write the function was that I have a webapp that sense text messages to
another system throughout the day. Problem is, that remote system isn't
available from 10am to 6pm. So, I needed at any point in time to be able
to check if the current time fell within that range.
As is the standard in this app, the current time is gotten with:
GregorianCalendar now = new GregorianCalendar();
Now, maybe there is a good argument to be made that doing that isn't the
best idea in the first place, but its what is throughout the codebase, so
it is what it is :) Anyway... having a Calendar object, just calling:
now.get(Calendar.HOUR_OF_DAY);
...gets me an int that is a 24-hour time, so 0-2359. Doing the range
check is just a number comparison at that point, hence the reason I took
that approach.
I'm not arguing that it's the best approach or anything, just giving the
rationale for the way I wrote the code :)
> I like the idea of the 'TimeRange' object that was mentioned earlier.
> I think that may make the simple hour & second calculations easier to
> deal with.
I agree too, as I think I did when it was mentioned. My only point about
it was that I'd like to be able to pass it a Calendar or even an int to
construct it, so that I just wrap what I now have in a TimeRange and off I
go. I'm a believer in providing as many overloaded versions of
utility-type functions and class constructors as possible so that as a
developer I have an easy time getting from one type to another.
> However, I think this would suffice only if the comparison takes place
> within a single day. Once the calculation spreads across multiple days,
> I think it would be better assisted with Date objects, to give it the
> additional context.
That's a fair point, however, you may not always know when a comparison is
going to span days, as is the case for me... even though I know the range
spans midnight because its in my webapp config file, the range could
change down the road and not span midnight. Certainly I don't want to
change code to accomodate the range change, and I shouldn't have to.
Whatever function I use to do the check should be smart enough to work
either way. If the snippet you posted here in fact does do that, then I'm
OK with it, again, as long as I can construct a Date off a Calendar so I
don't have to change a lot of existing code. :)
> If the difference in 2 Dates is required, then it may also be nice to
> create a simple class that can convert milliseconds (from
> Date.getTime()) into more useful units, like seconds, hours, days, etc.
> I understand that this is simple math, but it can also be repetitive,
> so it may be worth thinking about.
Nice suggestion... so nice in fact that I'd have a hard time believing
it's not out there already :)
> Again, this depends on the requirements. I may be going off on some
> weird tangents here.
Tangents? With me?!? No way! ;) (I'm known, I think, for wild tangents!)
>> 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. :)
>
> OK, sounds good. I'll try to clean it up and post it to Bugzilla when I
> get a chance.
Excellent! :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
