Attached is a patch file leap_seconds.patch against util-linux-2.22.2
that allows leap seconds to be included in hwclock --show or --hctosys.
The current code uses the default UTC zonefile in reading the hardware
RTC with mktime(). This zonefile usually does not include leap
seconds. As of this date there have been a total of 25 leap seconds
added since the epoch (start of 1970). This is particularly a problem
for systems using ntp to maintain their system clocks because ntp does
take leap seconds into account. A user can specify a leap-second-aware
zonefile via /etc/localtime. By defining the environment variable
TZUTC, mktime() can be induced to use a matching UTC zonefile that
includes leap seconds. The default behavior (TZUTC undefined) is
unchanged.
Regards,
Joseph Parmelee
jparmele at wildbear.com
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>
