docs: Fix adjtime documentation

The first line of the adjtime file is made of three numbers (see=20
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"=20 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=20 number.

Signed-off-by:: Pierre Labastie <pierre.labastie@neuf.fr>
Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/sys-utils/adjtime_config.5 b/sys-utils/adjtime_config.5
index 049d4c58528119af793c9c4e08347d29dda76996..239b90a87a3bbec116a66639aa711ca8b98c4be5 100644 (file)
--- 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 decimal)
 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 6c3a2e6ac8d225667fa785be0831ae0a058003d0..e62b4ad09d6b581c7a3b4da35890fb8f1dbcdd52 100644 (file)
--- 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