The first line of the adjtime file is made of three numbers (see
hwclock.c)
- a drift factor as a decimal float
- the time of last adjust as a decimal integer
- a zero (for compatibility) as a decimal float.
but both man pages (hwclock.8 and adj_time.5) tell that the third number
is a decimal integer.
Of course this is harmless if somebody edits the adjtime file with "0"
as
the third number: it will be correctly read by hwclock anyway.
But if for some reason, a program reads the adjtime file and expects an
integer, it will fail, because hwclock writes O.OOOO0O as the third
number.
Signed-off-by: Pierre Labastie <pierre.labastie@xxxxxxx>
---
sys-utils/adjtime_config.5 | 2 +-
sys-utils/hwclock.8.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sys-utils/adjtime_config.5 b/sys-utils/adjtime_config.5
index 049d4c585..fcdc7bf6c 100644
--- a/sys-utils/adjtime_config.5
+++ b/sys-utils/adjtime_config.5
@@ -36,7 +36,7 @@ the systematic drift rate in seconds per day (floating
point d
ecimal)
the resulting number of seconds since 1969 UTC of most recent
adjustment or calibration (decimal integer)
.TP
.B "adjustment status"
-zero (for compatibility with clock(8)) as a decimal integer.
+zero (for compatibility with clock(8)) as a floating point decimal.
.SS Second line
.TP
diff --git a/sys-utils/hwclock.8.in b/sys-utils/hwclock.8.in
index 6c3a2e6ac..e62b4ad09 100644
--- a/sys-utils/hwclock.8.in
+++ b/sys-utils/hwclock.8.in
@@ -652,7 +652,7 @@ in seconds per day, floating point decimal; 2) the
resulting number of
seconds since 1969 UTC of most recent adjustment or calibration,
decimal integer; 3) zero (for compatibility with
.BR \%clock (8))
-as a decimal integer.
+as a floating point decimal.
.PP
Line 2: One number: the resulting number of seconds since 1969 UTC of
most
recent calibration. Zero if there has been no calibration yet or it
--
2.24.0
