Silly season

Thu Dec 23 04:58:21 UTC 1999

>> Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit
>> time_t.  I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38,
>> but the date command would not set it.  Which implies that the kernel itself is
>> unsigned, while the date command uses a signed number.
>
>Wasting an entire 2 billion seconds to check for a -1 error condition
>instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But
>it would break a lot of userland programs to change. As far as I know in
>BSD it is still a signed long, at least in machine/ansi.h.

it's not signed just so that you can check for a -1 error condition,
it's signed so that you can say time "a" - time "b" gives number of
seconds "c", where "c" may be positive or negative (ie, the difference
between two points in time is easily presentable).  you may never have
used this particular functionality, but that's why it's there.

it's easy to say "just make it unsigned and you will win another 68
years!", but you have to consider *all* of the uses of a time_t.

the time in the (any) kernel is kept as signed so that it's in sync
with the rest of unix stuff.  you can call it unsigned, since it will
(probably) never go back beyond 1970, but that's picking nits.  as for
the kernel keeping time beyond 2038, it's just incrementing a kernel
variable.  there's no check in any c code you write for integer
overflow...it just goes negative.  try setting your clock to just
before the roll over, letting it roll over, and then touch a file and
see what ls says.  or date.  date probably just doesn't like to parse
things beyond that date.

it would be better, imho, to go to a 64 bit signed time_t, but that
would be a major flag day.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior at daemon.org             * "ah!  i see you have the internet
twofsonet at graffiti.com (Andrew Brown)                that goes *ping*!"
andrew at crossbar.com       * "information is power -- share the wealth."