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@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."