🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.linux.development.system
Article #145

Re: Year 2000 and Linux

#145
From: Gordon Scott
Date: Fri, 13 Mar 1998 00:00
52 lines
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-mail
References: <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