On Monday 14 December 2009, Martin Michlmayr wrote:
> Well, I'm not sure. But my assumption is based on this explanation:
> http://linux.die.net/man/2/adjtimex
What exactly in that man page explains how the time value gets corrected in
this specific scenario?
I don't see it.
adjtimex() sets "adjustment parameters" for the "clock adjustment
algorithm"; AFAICT it does not set the time itself.
> and the strace of ntpdate. gettimeofday() gives a strange result, but
> then adjtimex() is called and the result is used for settimeofday().
I don't think the time value itself gets changed there. It gets changed
before or after the adjtimex() call (probably before).
What the adjtimex() call probably does is reset any current "clock
adjustment" values because the forced setting of the clock by ntpdate
makes further gradual adjustment (assuming such adjustment may have been
started earlier by the ntp daemon) unnecessary.
> Whereas rdate simply passes the strange numbers to settimeofday().
AFAICT gettimeofday() does not give a strange result [1]. At least the
gmtime() function correctly returns the correct system date when it is
passed the time value returned by gettimeofday().
As you have just tested yourself (in a different mail exchange).
struct timeval tp;
struct timezone tzp;
struct tm *now;
if (gettimeofday(&tp, &tzp) == -1)
err(1, "Failed to get time of day");
now = gmtime(&tp.tv_sec);
After the above code, when run on a system where 'date' returns 08 Nov
1903, the value of now->tm_year is 3, which is exactly correct.
So, tp.tv_sec *must* have the correct (probably negative) time value.
Someone on IRC suggested that it might be caused by using 32-bit integers
in the calculation. Another cause could maybe be endianess.
My own C foo isn't strong enough to say what the exact cause is, but I'm
pretty sure it's a calculation bug in rdate.
[1] I agree it returns an unusual result which may require special
handling, but the result in itself seems accurate and to represent the
correct date.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
