Article View: comp.os.linux.development.system
Article #145Re: Year 2000 and Linux
From: Gordon Scott
Date: Fri, 13 Mar 1998 00:00
Date: Fri, 13 Mar 1998 00:00
52 lines
3216 bytes
3216 bytes
Chris Waters (cwaters@systems.dhl.com) wrote: : As for the 2038 end-of-epoch, I think we can safely wait till at : *least* 2001 before we start to panic. :-) Smiley noted ;-). There are a few other end-of-epochs that have given problems already, fortunately not in Linux which seems cleaner than some. However, many of us are are under pressure to make an "It's y2k compliant" statement on many diverse tools, products and packages. I do think that most of the problems are overstated, however I also expect to see a few fingers quite badly burned, substantially because we keep putting off the fix. Personaly, I suspect I've spent more money in the last decade engineering *around* it than has been saved on storage -- IMHO. I'm selling products built using tools supplied to me by organisations who *still* cannot tell me whether their tools are y2k compliant. When I find that they are *not* and I have to upgrade, I have a whole raft of verifying to do and a damnably short timescale in which to do it. One recently received upgrade has an incompatibilty that presently precludes its use!. One of those suppliers can't tell me, because _their_ supplier can't yet tell them. Some of these products go where they potentially have a risk to human life. For me, time is _already_ uncomfortably short. I don't yet have a need to 'panic', but am increasingly thinking that the next 18 months are beginning to look like very hard work indeed. We have a positive hard deadline here -- fortunately, software projects never ever overrun ;-> so there won't be a problem. Having that deadline should be helping us _all_ to focus on the whole problem _now_. IMHO this is our best chance to avoid propogating clock problems into the future. Have you ever been told that someone died because "your software didn't work"? I've have (actually, it wasn't true) and it's NOT a nice feeling! If someone proves negligence, it can also be a *very* expensive feeling. Fortunately, most of our sensitive stuff is either entirely in-house or rolls over every 24 hours, not every century -- but you can bet anything you like that there are a few sensitive things out there that don't. : (There *are* plans already in place for migrating to a 64-bit time_t.) Yup. Again, personally, I think we should be dealing^H^H^H^H^H^H have dealt with both together -- why fix two related problems separately? Gordon.
Technical Details
Message-ID:
<6ebcsp$2ek$1@sys-2-34.multitone.co.uk>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<541zwjlq6y.fsf@rrdjazz.nist.gov> <ckog1kqmj4x.fsf@systems.dhl.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5392,988a9a95e4afdf07 X-Google-Attributes: gidf5392,public X-Google-Thread: 11663c,988a9a95e4afdf07 X-Google-Attributes: gid11663c,public From: gordon@sys-2-34.multitone.co.uk (Gordon Scott) Subject: Re: Year 2000 and Linux Date: 1998/03/13 Message-ID: <6ebcsp$2ek$1@sys-2-34.multitone.co.uk> X-Deja-AN: 333710516 X-NNTP-Posting-Host: mepsys.demon.co.uk [193.237.39.216] References: <541zwjlq6y.fsf@rrdjazz.nist.gov> <ckog1kqmj4x.fsf@systems.dhl.com> Followup-To: comp.os.linux.development.system,dc.org.linux-users Organization: Multitone Electronics plc; Systems Development. Reply-To: Gordon Scott <gordon@mepsys.demon.co.uk> Newsgroups: comp.os.linux.development.system,dc.org.linux-users