oldbloke: (Default)
Add MemoryShare This Entry
posted by [personal profile] oldbloke at 03:56pm on 02/08/2006
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
There are 5 comments on this entry. (Reply.)
ext_8103: (Default)
posted by [identity profile] ewx.livejournal.com at 05:44pm on 02/08/2006
I'm still disappointed they didn't move to a 64-bit time_t in one of the glibc transitions of times past.
 
posted by [identity profile] imc.livejournal.com at 11:09pm on 02/08/2006
It already is on x86_64 platforms. No doubt they expect i386 to be obsolete long before 2038.
ext_8103: (Default)
posted by [identity profile] ewx.livejournal.com at 08:00am on 03/08/2006
The point of the posting was that you run into problems long before 2038.
 
posted by [identity profile] imc.livejournal.com at 08:33am on 03/08/2006
Anyone who uses a timeout value of 32 years deserves what they get, I tend to feel. If they'd used 1E10 instead, they'd have discovered the bug much sooner. :-)

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.
ext_8103: (Default)
posted by [identity profile] ewx.livejournal.com at 08:50am on 03/08/2006

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.


May

SunMonTueWedThuFriSat
        1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
12
 
13
 
14
 
15
 
16
 
17
 
18
 
19
 
20
 
21
 
22
 
23
 
24
 
25
 
26
 
27
 
28
 
29 30
 
31