Taskbar-Clock, hwclock, ClockVM(sys-net), sys-whonix, dom0 issues & improvements.

[RefinedSoftwareLLC]

Qubes OS version:

R4.0

Affected component(s):

Taskbar-Clock-Display, hwclock, ClockVM(sys-net), sys-whonix, and dom0

---

Steps to reproduce the behavior:

Shutdown PC, Use BIOS to change hwclock to local time (mine does not let me state a timezone), Start Qubes OS.
Taskbar-Clock-Display has wrong time.
sys-whonix fails whonixcheck with CLOCK_SKEW.
In ClockVM sudo hwclock shows -6 timezone offset (correct). In dom0 sudo hwclock shows -7 timezone offset (wrong) but if look at sudo hwclock --debug and manually count, it seams to really be using -6. This may just be a glitch in util-linux 2.28.2 that is fixed by util-linux 2.32.

Expected behavior:

Shutdown PC, Use BIOS to change hwclock to local time (mine does not let me state a timezone), Start Qubes OS.

Before starting sys-whonix Qube:

• Update ClockVM's, via NTP, by detecting the correct current UTC time and date.
• Update dom0's current UTC time from ClockVM.
• Update dom0's current date from ClockVM.
• Set ClockVM's timezone to dom0's timezone.
• Make sure that ClockVM & dom0 both are on daylight savings or both not.

Either:

A) Changes hwclock to always be UTC (Is this required for sys-whonix?).

• Change qvm-sync-clock to include , '--utc' with the final line of: subprocess.check_call(['hwclock', '--systohc', '--utc'], stdout=subprocess.DEVNULL)

B) Lets hwclock stay in localtime.

• Detect if hwclock is in localtime instead of UTC. It is only localtime if:
  -- hwclock is closer to localtime then UTC.
  -- hwclock is within 1.5 hours of correct localtime without daylight savings offset.
  -- hwclock is within 1.5 hours of correct localtime with daylight savings offset (Only if localtime uses daylight saving at all).
• Change qvm-sync-clock to branch, running hwclock with either , '--utc' or , '--localtime' depending on the previous detection.

Finally:

• Change qvm-sync-clock to set the hwclock of both dom0 and ClockVM (its virtualized hardware).
• Run qvm-sync-clock once.
• If needed, refresh Taskbar-Clock display.
• Then starts sys-whonix Qube (not before).

Also in Taskbar-Clock properties window:

• Button to update current time from NTP.
• Show dom0's timezone.
• Checkbox to "Set dom0's timezone to this" to the Taskbar-Clock's Timezone property (setting dom0 also sets ClockVM's timezone). If Timezone property is invalid or blank, default to UTC.
• If Taskbar-Clock's Timezone property is blank or invalid, default Taskbar display to dom0's timezone, not UTC. Currently, when invalid it defaults to UTC.
• Timezone dropdown list should popup city options without having to add America/ in front. Currently you have to type America/D instead of just D to see "America/Denver".
• Give visual feedback when Timezone property is invalid, maybe display underneath *Invalid timezone in red.

Actual behavior:

See "Steps to reproduce the behavior"

General notes:

The correct solution is not any of the following: "Its the users fault. No one else has this problem. Its a Linux issue not Qubes. It is working as intended. Works on my machine. This OS requires the command line to fix/set its main clock."

---

Related issues:

https://groups.google.com/forum/#!topic/qubes-users/ce7wVKvUmBc
#3374
https://groups.google.com/forum/#!topic/qubes-users/triKbPnvZSw
#3469