I'm working on a refclock driver for xntpd. My clock is connected like a
software dongle to the parallel port. I modified sys/dev/ic/lpt.c, added
an ioctl to talk to the clock and poll for its time.

As xntpd wants to calculate the difference between the time delivered by
the refclock and the internal kernel time, the new ioctl returns a timestamp
as well.

To get this timestamp, I call microtime() inside the driver.

Back in userland I'm trying to interpret the value I got from this call and
either I'm making some stupid mistake or my idea of "seconds since the epoch"
is somehow wrong - I'm ending up one day in the past!

Here is an example output from a small test program:

Date: 98-05-22 time: 23:27:59
kernel time: seconds = 895872485, microseconds = 325762
kernel time stamp: Fri May 22 21:28:05 1998 UTC

This indicates everything is fine (as my local time is UTC + 2 hours).

The last line was produced by this code:

	time_t kt;
	char buf[1024];
	kt = state.timestamp.tv_sec;
	strftime(buf, sizeof buf, "%c", gmtime(&kt));
	printf("kernel time stamp: %s UTC\n", buf);

Now when I do the math myself, I end up at different values:

It's 28 years sinc 1970, 7 of which were leap years. Start of this year
should have been at (28*365+7)*86,400 = 883,612,800.

The 22nd day of May, + 30 days of April, + 31 days of March, + 28 days of
Febuary, + 31 days of January give a day in the year of 142.

So start of the day should have been 883,612,800 + 142*86,400 = 895,881,600.
The time stamp at 21:28:05 adds an additional (21*60+28)*60+5 = 77,285.

So IMHO the above kernel time stamp should have been 895,958,885,
which is exactly one day (86,400) in front of the real time stamp above.

When I feed my values into xntpd, it syncs the date one day in the past,
so xntpd is calculating the same way as I am.

Is NetBSD's time library broken or am I doing something very stupid?
(This is on a 1.3.1 system, if that matters)


Any hints greatly appreciated...


Martin