Quoting Stephen J. Carpenter ([EMAIL PROTECTED]): > On Wed, Sep 30, 1998 at 11:01:22AM -0400, Michael Stone wrote: > > 2) 64 bit math is _very_ slow on a 32 bit machine. Since time_t is used > > all over the place (e.g., the filesystem) you'd seriously slow things > > down by making it 64 bits. > > Well heres an idea... > Currently time_t only USES 31 bits. Why? because it is signed! > if we were to make time_t unsigned then it would double the amount of > available time till the overflow > (by double I mean double from the epoch. that would mean 2038 ius the > halfway point... which gives us another 69 years after 2038...or > 2107) > > of course the ramifications of this would need to be tested... > hmm... wish I had a spare machine to try it on
You could get some pretty interesting results from subtracting dates if you did this. A signed number wasn't chosen just to waste space. > > 3) Since 64 bit archs already use a 64 bit time_t, this is a problem > > that will go away when 32 bit machines are phased out (I can't see most > > hardware lasting forty years.) > > I agree...but...they still could be. If you're using a pentium-class machine in 2038, you deserve what you get. I can't believe it would be operative after that long. > Isn't that exactly what the people who > were writting mainframe applications a few yars ago said? :) > > "Nah this system wont be in use past 93 forget about 99" Not exactly. Migrating the time_t is just a matter of recompiling an app. (Unless your app was written badly in the first place.) You can test that migration today by running your app on a 64 bit machine like an alpha. The y2k problems are largely caused by existing data and by inadequate _program specific_ data representations. If your program uses a proprietary representation, it will need to be rewritten; if your program uses time_t, it needs a recompile with a new libc. And as I said before, if your data is stored as a time_t, you _already_ have problems because that's not a portable solution. mike stone