I am also interested in this.
For regular App qubes, the very low update frequency and use of date instead of adjtimex causes very obvious steps in kernel time, which appear able to jump backwards in time if the hardware runs fast. Looks very naughty.
There is good information in an old thread:
…but I did not find the answer to this question.
Unsetting clockvm for the qube seems plausible. I did not test.
I considered setting the timer to a many year interval, using the file suggested, but this does not remove initial setting at qube startup and after suspend. Did not test.
I also considered using a policy change to block update, but it seems “wrong” to do that. Also not tested.
Will be very pleased to know the best method.
A warning: I did test all my system clocks using chronyd -x - some of them have very characteristic frequency errors - up to >10ppm, giving 0.25 second time jumps. I think this could allow de-anonymisation. It is not a problem for Whonix, I think.
If you disable the updates, then I think your qube will become even more easily identifiable online as its clock runs free, unless you will run a ntp-type or other synchronisation client on it. (not necessarily a problem for vault, but any time-based OTP will stop working at some time)