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.
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 ]
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.