I don't think that anything in the API documentation suggests that it is.

xruns, whether caused by clients or kernel scheduling, essentially reset the clock. nothing in jack1 (and i believe nothing in jack2) attempts to maintain clock consistency (monotonicity or linearity) across xruns.

of course, there is a legitimate argument that this would be useful, but it would require (as far as i can tell) a bunch of assumptions that while often correct, are not really solid. most of them relate to the ability to continue using a DLL that links a system clock and the audio clock across a restart of the audio clock (since the system clock is the only thing that could keep running as far as JACK is concerned).