File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Daily Time Calculation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of The Software Craftsman this week in the Agile forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Daily Time Calculation" Watch "Daily Time Calculation" New topic

Daily Time Calculation

Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3740

In an issue thats sort of related to this post, I have a set of code that I 'inherited' to perform daily schedule calculation that I've never quite trusted. Awhile back I searched for other ways to do this, and to my dismay other websites had similar solutions. I'll post a description here and see if anyone can significantly improve on the subject...

It's a little simplified in that more complicated paths (such as if no start time is specified) is left out of the equation.

My understanding of it is that since only the time is specified in the database, getTime() in JDBC will return a time of day as related to the epoch, therefore you need to convert the current time to the time of day at the start of the epoch to perform the calculations.

Is there a better way to do this? One solution might be to use Calender.get(HOUR_OF_DAY), Calendar.get(MINUTE), etc to perform the comparison manually, but that seems like then your reimplementing date/time comparison with a slower process than just using millisecond comparison.

[OCA 8 Book] [Blog]
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I don't know, but I don't really trust java.sql.Time very much. The specs seem too ambiguous to me - while most of the time they talk about Jan 1, 1970 GMT, in some cases they omit the GMT part. And if you use a Calendar that's not set to GMT you may get different results. Furthermore I don't know if I would trust that all JDBC drivers will interpret this the same way either.

More generally, schedules might wrap around midnight - either midnight EDT or midnight GMT, whichever one is really relevant. Maybe this will never be an issue for you, but it seems risky to me. It would be a bigger issue on the West coast or in Asia, I guess. I would check whether or not endTime comes after startTime. If not, you've probably wrapped around midnight. Be sure to test the method with times between 8 PM EDT and midnight (and just after), to see if they're working correctly.

With luck, correct handling of midnight wrapping will make it so it doesn't matter whether the problem is midnight GMT or midnight EDT. I think this might work:

As for elegance/efficiency concerns, while there are many ways to do this sort of calculation, I don't see any that are significantly better than what you're doing above. If you're repeating this calculation many times in a loop, you may want to refactor the code to create the currentTimeOffsetFromEpoch outside the loop. But that's sort of obvious if your code has a big loop like that, an unnecessary otherwise. I have no clever idea to add here.
[ April 29, 2008: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Paul Clapham

Joined: Oct 14, 2005
Posts: 19357

It might be better to can the whole mess and rewrite it using Joda Time. (Or maybe not.) I haven't used it myself but I see it supports for example periods, which make it very easy to add a month to an instant of time.
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3740

Originally posted by Jim Yingst:
you may want to refactor the code to create the currentTimeOffsetFromEpoch outside the loop.

In the actual implementation it is since it compares itself against numerous schedules.
Consider Paul's rocket mass heater.
subject: Daily Time Calculation