Starting on May 12, 2006, many installations of the AOLServer web server
failed. [snip techy stuff]
It was then noted by a perceptive
person that the servers all failed on or before exactly one billion seconds
before the end of the Unix epoch in 2038. Many installations had very long
database timeouts, which caused the software to look ahead and see the End
of Time. [more snips]
The thread discussing the problem and its resolution is here:
http://www.mail-archive.com/aolserver@listserv.aol.com/msg09812.html
failed. [snip techy stuff]
It was then noted by a perceptive
person that the servers all failed on or before exactly one billion seconds
before the end of the Unix epoch in 2038. Many installations had very long
database timeouts, which caused the software to look ahead and see the End
of Time. [more snips]
The thread discussing the problem and its resolution is here:
http://www.mail-archive.com/aolserver@listserv.aol.com/msg09812.html
(no subject)
(no subject)
(no subject)
(no subject)
If you're going to change the type of time_t, you need something that is a plug-in replacement for "long" (so people can do arithmetic on it) and isn't a gcc extension (other compilers exist for Linux). I gather that "long long" is part of the C99 standard (are all compilers expected to support it yet?). You probably also want to change the kernel's time_t at the same time, which may be non-trivial to arrange.
(no subject)
32 year timeouts are a little silly for a web server but 32-year intervals might be rather short for applications involving, say, human lifetimes.
If anyone's really still using an obsolete compiler which doesn't have 64-bit integral types then they're already missing a whole bunch of stuff from Glibc. Still, it would not be impossible to arrange for those compilers to get the old 32-bit interface.
The kernel can add a 64-bit time type whenever it likes and does not have to be coupled to the library at all; they can happen in either order, though it's only really useful once the library has it.