Messages in this thread | | | Date | Mon, 5 Jan 1998 16:49:08 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: Y2k - Is Linux Ready for the year 2000? |
| |
> I need documentation concerning Linux's year 2000 compliancy, can anyone > point me to it?
I don't know that you'll find much documentation, since Y2k is a relative non-issue for most modern UNIX kernels. (See POSIX 1003.1b-1993, aka POSIX.4) It's primarily an issue for poorly-written user applications and databases.
The kernel expresses dates using the UNIX epoch, i.e., a measure of seconds since 00:00AM Jan 1 1970 GMT. Using a 32-bit signed representation of seconds, the system clock will overflow sometime in 2038 (the Y2038 problem, don't hear much hype about that...guess it just doesn't have a good "ring" to it, that and it's 40 years off), using unsigned buys us another 68 years. Hopefully by then we'll all be on 64-bit machines (at least), which won't overflow for another 290 or 580 billion years (approximate, signed vs unsigned). (I may be off by a power of 2 on these, feel free to double-check me; I tend to not care when dealing with timespans on the order of a star's life expectancy.)
That's just the kernel; most well-written software will use the same UNIX clock, but I'm sure there are some poorly written applications out there (or applications with particular reasons for choosing another date/time encoding) that will rollover before then. If you need documentation of which individual applications are compliant, The only way to check that is to ask the authors or read the source. GNU can probably verify most of their stuff for you, but beyond that you're really on your own... (the Linux Software Map can give you e-mail addresses for lots of authors...)
Adam -- Things look so bad everywhere Adam D. Bradley artdodge@cs.bu.edu In this whole world what is fair Boston University Computer Science We walk blind and we try to see Ph.D. student and Linux hacker Falling behind in what could be ----> Bring me a Higher Love ----> <><
| |