Network Time Synchronization
A reasonably accurate host clock is required for many general security properties. An inaccurate clock can lead to broken internet connectivity and time related security issues.
It is recommended to have a host clock with accuracy of up to ± 30 minutes. Clocks that are days, weeks, months or even years slow or fast can lead to many issues such as connectivity problems with Tor, inability to download operating system upgrades. 
Follow the platform-specific recommendations below to avoid Tor connectivity problems and to limit possible adverse security impacts.
If the host clock is more than 1 hour in the past or more than 3 hours in the future, Tor cannot connect. In this case, manually fix the host clock by right-clicking on it, and also check for an empty battery.
- If using Kicksecure as a host operating system: Reboot. (Easiest.)
- If using a VM: Then, power off and power on Kicksecure and Tor should be able to reconnect.
- Due to Block Networking until sdwdate Finishes if Tor failed or took too long to connect, then you need to fix Tor connection first and then restart your sdwdate
sudo systemctl restart sdwdatein your VM/Qube.
Kicksecure in VMs or as a host operating system: It is strongly discouraged to use the pause / suspend / save / hibernate features.
Kicksecure for Qubes VMs: It is strongly discouraged to use the pause feature of Qube Manager, but it is is safe to use the suspend or hibernate feature of dom0.
If you are interested in using the pause / suspend / save / hibernate features, please click the expand button for further instructions.
Kicksecure as a host operating system or VM:
- It is strongly discouraged to pause / suspend / save / hibernate Kicksecure. If this advice is ignored, restart sdwdate after resume. 
Kicksecure for Qubes:
Start Menu →
Time Synchronization Monitor (sdwdate-gui) →
Or in a terminal. 
Manually Set Clock Time and Date
Usually not required.
In case sdwdate fails to properly randomize the system clock, it is possible to manually set a random value.
The first step should be completed on the host to ensure the host clock is set to the correct time.
1. On the host (Kicksecure for Qubes:
dom0), run the following command to report the time in UTC.
The output should be similar to the following. 
Sep 26 23:22:44 UTC 2023
2. Set the correct time in Kicksecure.
clock-random-manual-gui: a randomized clock setting (in UTC) is entered via a GUI.
clock-random-manual-cli: a randomized clock setting (in UTC) is entered on the command line. For example :
echo "Sep 26 23:22:44 UTC 2023" | sudo clock-random-manual-cli
3. Restart sdwdate.
sudo service sdwdate restart
4. If Tor is still not functional, try restarting Tor.
sudo service tor restart
Tor should work once correct clock values are set, but that can be manually tested with systemcheck.
Block Networking until sdwdate Finishes
sdwdate is a Tor-friendly replacement for rdate and ntpdate that sets the system's clock by communicating via end-to-end encrypted TCP with Tor onion webservers. Since timekeeping is crucial for security, blocking network access until sdwdate succeeds is sensible. 
Note: When using this feature, there will be no internet connectivity until sdwdate succeeded which could take approximately 2 minutes.
Table: Network Time Synchonization Summary
Deactivate Automatic TimeSync
To deactivate sdwdate, run.
sudo service sdwdate stop
sudo systemctl mask sdwdate
- Due to invalid (not yet or no longer valid) TLS certificates.
Similarly, if users suspend or save the Kicksecure state, the clock will again lag behind the correct value. This can be manually fixed by running:
Time Synchronization Monitor (sdwdate-gui)→
Qubes does not dispatch the
/etc/qubes/suspend-pre.dhooks upon pause / resume using Qube Manager.
- Simplified in next upgrade. sudo sdwdate-clock-jump
- Mon Apr 22 04:30:44 UTC 2019
A non-zero exit codes signifies an error, while
0means it succeeded.
- Also see: man clock-random-manual-gui man clock-random-manual-cli
- echo "Sat Oct 26 07:18:25 UTC 2019" | /usr/bin/clock-random-manual-cli