A sideeffect of 839be2ba6b is that we now
warp the systemtime according to the timezone, on the first call of
--systz. This is not always the correct thing to do, and causes a
regression for us in Arch Linux.
The behavior is correct if the RTC, and hence the systemtime, is
in localtime. However, if the systemtime is already in UTC we don't
want to touch it when we set the kernel timezone (which we still need to
do as some filesystems use this information).
An almost identical issue was also fixed in systemd commit
72edcff5db936e54cfc322d9392ec46e2428fd9b.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The new option imitates adjtimex -c functionality and outputs
the drift in 10 second intervals.
[kzak@redhat.com: - coding style
- print hw and system time columns too]
Signed-off-by: Karel Zak <kzak@redhat.com>
Not sure why, but the current --systz uses non-NULL timeval for
settimeofday(). It means that build-in kernel warp clock mechanism is
not used and the system time is always modified.
The built-in kernel implementation allows to move the clock by
timezone only for very first settimeofday() call.
Signed-off-by: Karel Zak <kzak@redhat.com>
