[ On , August 21, 2002 at 16:27:36 (-0700), Wolfgang Rupprecht wrote: ]
> Subject: Re: microtime
>
> 
> It always struck me that allowing leap seconds to wrench the system's
> time was a bit like keeping the kernel time in local-wall-time and
> then pulling some elaborate slight of hand during the
> daylight-savings-time transitions.

I couldn't agree more!  ;-)

> I recall reading Bernstein's proposals to keep the kernel time in
> purely monotonically increasing seconds and simply using the Olson
> time-printing code in libc in its other mode where is would add the
> leap seconds in only at time display time.  Are there any technical
> gotcha's that would bite one in the butt if the leap seconds were
> moved out of the kernel's time?

Well, that's exactly the way time(3) is defined _now_.

     The time() function returns the value of time in seconds since 0 hours, 0
     minutes, 0 seconds, January 1, 1970, Coordinated Universal Time.

     The time() function conforms to IEEE Std 1003.1-1990 (``POSIX'').

The result of time() is not supposed to be wall-clock time in the UTC
timezone -- it's supposed to be the number of seconds since the defined
epoch time.  Leap seconds, leap days, an other weirdness is supposed to
be an artifact of the real world, just like timezone offsets, etc.

So, if the result of time() jumps around, i.e. is not exactly the full
count of seconds since the defined epoch, then it's already broken.

gettimeofday(2) is also supposed to be elapsed time since the epoch,
though of course it's not specified by POSIX or ANSI/ISO C.

Only localtime() and gmtime() (and I guess ctime()) should correct for
leap seconds, leap days, timezone offset, etc. and produce a result
equivalent to wall-clock time of day as of the time-since-epoch value
they were asked to convert.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>