The current implementation of Session.checkSessionTime() has a race condition caused
by multiple calls to System.currentTimeMillis(). (Not a thread access race, but a race against
the wall clock.) This will not be caught by the Junit tests unless you happen to be running them
right around midnight on a slow computer, but it's QUITE LIKELY to be seen in a running server
with multiple sessions open every night!

Suppose the method is entered just before midnight UTC, e.g. 23:59:59.999, and the clock has
not yet ticked over by the time the SessionSchedule fields are updated by adjustSessionTimes.

But then the calls to "getTimeOnly" occur after the clock has ticked over and isDailySessionTime
starts comparing times from yesterday against the new "time only" calendar instance.

The end result is a "false" return from checkSessionTime when it really should be true, leading
to disconnect.