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 ]