North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Silly season
>> 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" >-----| [email protected] * "ah! i see you have the internet [email protected] (Andrew Brown) that goes *ping*!" [email protected] * "information is power -- share the wealth."
|