🚀 go-pugleaf

Followup to:  <541zwjlq6y.fsf@rrdjazz.nist.gov>
By author:    Przemek Klosowski <przemek@rrdjazz.nist.gov>
In newsgroup: comp.os.linux.development.system

> Someone asked me about Y2K and Linux, and I wrote the enclosed 
> answer. Now they want to actually use it in some internal document,
> so I thought I'd ask around for people to review it for accuracy.
> 
> I understand that Linux kernel doesn't have any year 2000 issues
> (dates are kept as 32-bit integers denoting the number of seconds
> since 1970, so this will last without any problems until 2^31 seconds
> will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
> incorrectly interprets the date as signed integer.  For correctly
> written software it will be yr. 2106 when the date will overflow.

Incorrect.  time_t is *PROPERLY* signed; negative time_t's refer to
dates before Jan 1, 1970 00:00:00 UTC.  Interpreting time_t's as
unsigned is a bug.  We should have migrated to a 64-bit time_t long
before 2038; a 64-bit time_t can represent times on a cosmological
scale.

> Applications rarely use the 2-digit format; I personally don't know of
> any that does that.

Some old versions of date and cvs have these problems; the up-to-date
versions don't.

> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, so that loading the system
> clock on bootup from the hardware clock would result in a 1900 date in
> year 2000. This is easy to fix; simply, getting years 00 to 90 from the
> stupid hardware clock will result in adding 2000, not 1900, to the
> year, and we are good for 90 more years. Since Linux didn't exist before
> 1990, it is not going to cause problems :^)

This is correct.

	-hpa
-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah�'� -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Mis�rables

Przemek Klosowski <przemek@rrdjazz.nist.gov> writes:

> Someone asked me about Y2K and Linux, and I wrote the enclosed 
> answer. Now they want to actually use it in some internal document,
> so I thought I'd ask around for people to review it for accuracy.

looks pretty good to me, a few minor nits...

> I understand that Linux kernel doesn't have any year 2000 issues
                                ^ and glibc
> (dates are kept as 32-bit integers denoting the number of seconds
                    ^ signed
> since 1970, so this will last without any problems until 2^31 seconds
> will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
> incorrectly interprets the date as signed integer.  For correctly
> written software it will be yr. 2106 when the date will overflow.

no, time_t is defined as a signed integer, so it will hit in 2038 for 32
bit platforms (ie, x86).  I'm pretty sure it's a signed 64 bit on 64 bit
platforms such as alpha and sparc64, which gives you a time range
signifigantly greater than the expected age of the sun.

> Applications rarely use the 2-digit format; I personally don't know of
> any that does that.

cvs 1.9 does it, this is already fixed in the current testing versions, and
a few older packages such as older versions of gnu fileutils were
vulnerable. 

> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, so that loading the system
> clock on bootup from the hardware clock would result in a 1900 date in
> year 2000. This is easy to fix; simply, getting years 00 to 90 from the
> stupid hardware clock will result in adding 2000, not 1900, to the
> year, and we are good for 90 more years. Since Linux didn't exist before
> 1990, it is not going to cause problems :^)

also synching the time from a time server will set the OS clock correctly. 

-- 
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.res.wpi.net RH 5.0 kernel 2.0.33/2.1.89p5 i586 | at public servers
"Never make any mistaeks."
(Anonymous, in a mail discussion about to a kernel bug report.)

Przemek Klosowski wrote:
> 
> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, so that loading the system
> clock on bootup from the hardware clock would result in a 1900 date in
> year 2000. This is easy to fix; simply, getting years 00 to 90 from
> the
> stupid hardware clock will result in adding 2000, not 1900, to the
> year, and we are good for 90 more years. Since Linux didn't exist
> before
> 1990, it is not going to cause problems :^)

This is not as easy as it sounds. Someone associated with the ACM did
a study of "freeware" (and even many copyleft) packages and found that
there were quite a few that assumed the 20th century when using
functions
like localtime(3). This is not only a problem with Linux/Unix, but 
the Microsoft-based operating systems, too

There is a problem with Linux and ALL systems if the hardware clock
does not properly report the time correctly on reboot. In an informal
study on a 486 with a bad BIOS, the following happened:

	+ cron stopped working because it got "confused" by the bad
	  time value.
	+ NIS stopped working.
	+ The system will never sync properly with an NTP host. The
	  testers did not examine why this failed.
	+ Programs that use the time value as a signed long (which is
	  what time_t is) will not compare correctly. The testers did
	  figure out that the time was being set to the epoch (1/1/70)
	  plus the internal clock's offset.

Unfortunately, there is not a lot of "analysis" with the study.
The testers did not have the time. However, they did find that Linux was
fairly Y2K compliant, as long as the apps are Y2K compliant. Linux, like
all x86-based operating systems, have problems when the BIOS does not
accuratly report the system clock time on reboot.

Recently, a federal contractor had a problem with a Pentium-based system
whose BIOS was not Y2K compliant. It shut down the project for 3 1/2 
months before they found that the BIOS was the problem. Once they
swapped
the ROMs, the problems were solved! This system was running a version of
UNIX.

Moral: No x86-based system is Y2K compliant, regardless of the
precautions
made in software, if the BIOS is not!

Moral (2): If you are using a system manufactured prior to 1998, make
sure
you check the BIOS first! The federal contractor mentioned above was
using
a well known vendor's 150MHz Pentium-based system bought during the
summer
of 1997.

scott barman
barman@ix.netcom.com

In <541zwjlq6y.fsf@rrdjazz.nist.gov> Przemek Klosowski <przemek@rrdjazz.nist.gov> writes:
>
> will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
> incorrectly interprets the date as signed integer.  For correctly
> written software it will be yr. 2106 when the date will overflow.

time_t must be signed, or things like difftime wont work correctly,
and gettimeofday returns -1 on an error.

Trying to fix the problems with switching from signed to unsigned
time_t isn't worth it.  Just switch to a 64-bit time_t instead.


> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, [ .. ]

no, there are *lots* of places that you can run into trouble.  All
sorts of "system" commands such as date, ls, find, touch, etc. may not
be y2k compliant (they have failed on other Unix systems...).  It is
even possible that certain device drivers could break.  And then there
are the oodles of applications that may break.  Does netscape work
correctly?  What about ntp or nntp?  Does xv write any timestamps in
anywhere?


While Unix may be much better off than other operating systems, it is
certainly not a *given* that everything will work.  If you want to be
sure that things work in the year 2000, get a machine with the
software that you want to run and *test* it during the roll over and
beyond.


-wayne



-- 
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

Wayne Schlitt <wayne@midwestcs.com> writes:

>time_t must be signed, or things like difftime wont work correctly,
>and gettimeofday returns -1 on an error.

Why?  Difftime doesn't return a time_t.  It returns a double.
gettimeofday doesn't return time.
time() doesn't even return -1.

Oops, mktime() returns -1.

>Trying to fix the problems with switching from signed to unsigned
>time_t isn't worth it.  Just switch to a 64-bit time_t instead.

Which might be a bit hard for on-disk formats and such.


Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

>>>>> "Casper" == Casper H S Dik <Casper.Dik@Holland.Sun.Com> writes:


  Casper> Oops, mktime() returns -1.

mktime() returns (time_t)-1.   That could be a different thing.

In <6disqv$iut$1@hirame.wwa.com> nospam@wwa.com (Bloody Viking) writes:
> 
> [ ... ]                                                         Linux
> takes advantage of the 2038 rule as it was invented much later and thus,
> every year within Linux's "life" is unique even without a century byte. 

I'm not sure where you dug this "information" up, but the format for
time/dates that Linux uses is the same as for all other versions of
unix (well, some now use 64bits instead of 32, but..).  Unix was
invented about 10 years before MS-DOS, so it is hardly a newer
format.

-wayne



-- 
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.

[cross--posted to c.s.y2k in order to solicit criticism.  --Z]

[c.s.y2k'ers:  READ THE THRAD in c.o.l.d.s. before 
following-up!  --Z]


In article <541zwjlq6y.fsf@rrdjazz.nist.gov>,
Przemek Klosowski  <przemek@rrdjazz.nist.gov> wrote:
>
>Someone asked me about Y2K and Linux, and I wrote the enclosed 
>answer. Now they want to actually use it in some internal document,
>so I thought I'd ask around for people to review it for accuracy.
>
>
>
>I understand that Linux kernel doesn't have any year 2000 issues
>(dates are kept as 32-bit integers denoting the number of seconds
>since 1970, so this will last without any problems until 2^31 seconds
>will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
>incorrectly interprets the date as signed integer.  For correctly
>written software it will be yr. 2106 when the date will overflow.
>
>Applications rarely use the 2-digit format; I personally don't know of
>any that does that.
>
>The only place where you might run into trouble is because computer
>hardware clock maintains the 2-digit date, so that loading the system
>clock on bootup from the hardware clock would result in a 1900 date in
>year 2000. This is easy to fix; simply, getting years 00 to 90 from the
>stupid hardware clock will result in adding 2000, not 1900, to the
>year, and we are good for 90 more years. Since Linux didn't exist before
>1990, it is not going to cause problems :^)
>
>
>-- 
>			przemek klosowski <przemek@nist.gov>  (301) 975-6249
>			NIST Center for Neutron Research (bldg. 235), E111 
>			National Institute of Standards and Technology
>			Gaithersburg, MD 20899,      USA
>                        .. and for spam extractors, FCC Commisioners' email is: 
>			wkennard@fcc.gov,sness@fcc.gov,pmisener@fcc.gov,mpowell@fcc.gov

Zooko Journeyman (zooko@xs4all.nl) wrote:
: [cross--posted to c.s.y2k in order to solicit criticism.  --Z]

: [c.s.y2k'ers:  READ THE THRAD in c.o.l.d.s. before 
: following-up!  --Z]

: >The only place where you might run into trouble is because computer
: >hardware clock maintains the 2-digit date, so that loading the system
: >clock on bootup from the hardware clock would result in a 1900 date in
: >year 2000. This is easy to fix; simply, getting years 00 to 90 from the
: >stupid hardware clock will result in adding 2000, not 1900, to the
: >year, and we are good for 90 more years. Since Linux didn't exist before
: >1990, it is not going to cause problems :^)

I run Linux on 2 known-noncompliant boxes, and Linux takes care of it's
dating with just the clock with no need for the century byte. DOS needs
the century byte however. Using a BIOS tester in DOS, my Packrat Bell both
fails the "boot after the party" and "run during the party" test. The
clock rolls back to 1900 in both cases, but Linux keeps the correct date
in both cases by software reading the clock and using the 2 digits. Linux
takes advantage of the 2038 rule as it was invented much later and thus,
every year within Linux's "life" is unique even without a century byte. 

Happy New Year!

--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
                     "A man's car is his battleship"

2109585 bytes of spam mail deleted.           http://www.wwa.com/~nospam/

In article <casper.889020671@uk-usenet.uk.sun.com>,
Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.Com> wrote:
>Oops, mktime() returns -1.

Well, according to my manual page:

       If the specified broken-down time cannot be represented as
       calendar  time,  mktime()  returns a value of (time_t)(-1)

So it returns (time_t)-1, which is something else ..

Just nitpicking ..

Mike.
-- 
 Miquel van Smoorenburg |  
    miquels@cistron.nl  |  Luck is when preparation meets opportunity

Wayne Schlitt (wayne@midwestcs.com) wrote:

: I'm not sure where you dug this "information" up, but the format for
: time/dates that Linux uses is the same as for all other versions of
: unix (well, some now use 64bits instead of 32, but..).  Unix was
: invented about 10 years before MS-DOS, so it is hardly a newer
: format.

While Linux shares the one signed integer register with "real" UNIXes, the
obtaining of what's in it has to come from the hardware clock and
converted into the classic UNIX style. 

What Linux is doing is taking the hardware clock's output and then
converting it to the UNIX 32-bit format, and using the existing clock,
compensating for 1900 == 2000. Works great in my tests on the noncompliant
boxes.

--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
                     "A man's car is his battleship"

2117795 bytes of spam mail deleted.           http://www.wwa.com/~nospam/

H. Peter Anvin (hpa@transmeta.com) wrote:
: > The only place where you might run into trouble is because computer
: > hardware clock maintains the 2-digit date, so that loading the system
: > clock on bootup from the hardware clock would result in a 1900 date in
: > year 2000. This is easy to fix; simply, getting years 00 to 90 from the
: > stupid hardware clock will result in adding 2000, not 1900, to the
: > year, and we are good for 90 more years. Since Linux didn't exist before
: > 1990, it is not going to cause problems :^)

: This is correct.

Yes, but Unix, whose design Linux mimics, did exists prior to 1990.

Larry

In <casper.889020671@uk-usenet.uk.sun.com> Casper.Dik@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:

>time() doesn't even return -1.

Not on Linux, but the C standard requires it to return (time_t)-1 if the
time information is not available.  Of course, this does NOT mean that
time_t must be a signed type.  It's a signed type for portability reasons
only.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

In article <6dmenj$4av$1@news1.mnsinc.com>,
Larry Mintz <mintz@mnsinc.com> wrote:
>H. Peter Anvin (hpa@transmeta.com) wrote:
>: > The only place where you might run into trouble is because computer
>: > hardware clock maintains the 2-digit date, so that loading the system
>: > clock on bootup from the hardware clock would result in a 1900 date in
>: > year 2000. This is easy to fix; simply, getting years 00 to 90 from the
>: > stupid hardware clock will result in adding 2000, not 1900, to the
>: > year, and we are good for 90 more years. Since Linux didn't exist before
>: > 1990, it is not going to cause problems :^)
>
>: This is correct.
>
>Yes, but Unix, whose design Linux mimics, did exists prior to 1990.
>

Right, You may want to read a tar file from even the 1970's.
We had best leave the epoc as 1970 like it has always been.
Simply goto 64 bits time before 2038.

In article <casper.889020671@uk-usenet.uk.sun.com>,
Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.Com> wrote:
>Wayne Schlitt <wayne@midwestcs.com> writes:
>>Trying to fix the problems with switching from signed to unsigned
>>time_t isn't worth it.  Just switch to a 64-bit time_t instead.
>
>Which might be a bit hard for on-disk formats and such.

Good point, but after the y2k thing is over you will still
have more then 30 years to switch to a new file system.
You will need new hardware in 30 years -- switch then.

We will need the new 64bit version of tar should read
the old 32bit tar files and set the old dates correctly.
same goes for cpio and what ever else you use.
Still, we have a bit of time to think about that.

Does any body realy know what time it is.
Does any body realy care ... About time.	-- Chicago

In article <EpEp2M.Bqs.0.cb2@apgea.army.mil>,
bobs@apgea.army.mil (J.R.Suckling) wrote:
> In article <casper.889020671@uk-usenet.uk.sun.com>,
> Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.Com> wrote:
> >Wayne Schlitt <wayne@midwestcs.com> writes:
> >>Trying to fix the problems with switching from signed to unsigned
> >>time_t isn't worth it.  Just switch to a 64-bit time_t instead.
> >
> >Which might be a bit hard for on-disk formats and such.
> 
> Good point, but after the y2k thing is over you will still
> have more then 30 years to switch to a new file system.
> You will need new hardware in 30 years -- switch then.

That works well if you only have one machine.
-- 
Shields, CrossLink.

J.R.Suckling wrote:
> 
> In article <casper.889020671@uk-usenet.uk.sun.com>,
> Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.Com> wrote:
> >Wayne Schlitt <wayne@midwestcs.com> writes:
> >>Trying to fix the problems with switching from signed to unsigned
> >>time_t isn't worth it.  Just switch to a 64-bit time_t instead.
> >
> >Which might be a bit hard for on-disk formats and such.
> 
> Good point, but after the y2k thing is over you will still
> have more then 30 years to switch to a new file system.
> You will need new hardware in 30 years -- switch then.
> 
> We will need the new 64bit version of tar should read
> the old 32bit tar files and set the old dates correctly.
> same goes for cpio and what ever else you use.
> Still, we have a bit of time to think about that.

What really bothers me about the present y2k problem is that the engineers
_had_ plenty of time to "think about that". I often wonder if the whole Y2K
problem isn't emblematic of a very jaundiced world-view: the engineers
literally didn't think (on a subconscious level maybe?) that there was any
possibility that we'd even make it to the Year 2000 - and thus didn't
anticipate ever having to deal with a century nor a millenium rollover. It's
as if people didn't try to forestall a technical doomsday because they didn't
anticipate anyone having the technology nor perhaps even the lives to run
software after the year 2000.

I can't even with tongue-in-cheek start to elaborate upon just how many "after
the bomb" science-fiction stories have been shot down in flames by the Y2K
problem. You know, ( (c) copr 1998 TJH Internet SP) first gasp of a renascent
civilization discovers an archival artificial intelligence which mysteriously
blinks to life after a ten-century hiatus despite no I/O or powersupply... and
suddenly it hits the simple fact that it's reading a date some 50 years before
it was programmed, decides it's traveled back in time (quite an imaginative AI
there) and promptly goes mad trying to analyze the impacts its actions in what
it thinks is the now will have on its own development. Okay, so I could do a
precis. But I can't elaborate on it because it's all too silly and beside
probably Silverberg has done it before. 

I guess that if there's one thing learned from this whole mess it's this: if
your business is programming you're dealing a lot with sequence and branching.
Well, how could anyone in good conscience not plan for something like a mere
turn-of-century? It's just extended sequence. I can understand it in terms of
saving memory back when computers had a whole 14K of magnetic core, but
anytime after maybe 1992 it simply doesn't make sense and I cannot believe
that nobody saw this coming.

So if anyone is going to start writing for the future I guess I hope they'll
be writing for, as someone else put it, "cosmological timescale" and we SF
writers who dabble in computing can go back to writing stories about undying
artificial intelligences that can lie buried beneath the wreckage of
civilization to fortuitously aid in the rennaisance of civilization millenia
hence etc yadda yadda - without causing anyone knowledgable to fall down
laughing "but what about Y2K?"

Sorry for the rant.


-- 
Be kind to your neighbors, | "When the going gets weird the weird turn pro."
even though they be        | http://www.clark.net/pub/klaatu/home.html 
transgenic chimerae.       | Now. Chock full of uninteresting links. 
--------- Whom thou'st vex'd waxeth wroth ----------------
Non-UseNet re-transmission of this news article is a willful violation of US
Copyright Law and the Berne Convention. Statutory damages are $250,000.00
         Re-transmission of this e-mail expressly prohibited. 
The e-mail addresses  for the FCC Commissioners include 
rhundt@fcc.gov, jquello@fcc.gov, sness@fcc.gov, rchong@fcc.gov

J.R.Suckling (bobs@apgea.army.mil) wrote:
: Good point, but after the y2k thing is over you will still
: have more then 30 years to switch to a new file system.
: You will need new hardware in 30 years -- switch then.

Now where have I heard that before -- Oh yes, I remember, back
in the 70's when 8-bit micro's cost as much as a small car and
memory wasn't so cheap as is it is now. We'll fix it when we go
16bit, heck -- we have nearly 30 years to do this and we'll need
new hardware before then.

By the early 80's it was already getting hard to change, but heck
-- we have nearly 20 years yet......

We have nearly a decade...

We have a couple of years...

If we botch around it some more we can hide the problem....

We have to fix this some time, and the longer we leave
it the more it will hurt.

Gordon.

gordon@sys-2-34.multitone.co.uk (Gordon Scott) writes:

> Now where have I heard that before -- Oh yes, I remember, back
> in the 70's when 8-bit micro's cost as much as a small car and
> memory wasn't so cheap as is it is now. We'll fix it when we go
> 16bit, heck -- we have nearly 30 years to do this and we'll need
> new hardware before then.

I've heard some estimates that the amount of money saved by using
two-digit dates (saving on storage costs) was *more* than enough to
compensate for the costs of running around madly at this late date
trying to retrofit the world to have more than 100 years of
existence.

As for the 2038 end-of-epoch, I think we can safely wait till at
*least* 2001 before we start to panic.  :-)

(There *are* plans already in place for migrating to a 64-bit time_t.)
-- 
Chris Waters             | Bill Gates: "We need room to innovate!"
cwaters@systems.DHL.COM  | 
xtifr@dsp.net (personal) | Me: "Well, that would certainly be a change."
www.dsp.net/xtifr/ (web) | 

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.

gordon@sys-2-34.multitone.co.uk (Gordon Scott) writes:

> 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.

Yup, I certainly have been.  Which is why I want to wait till at least
2001 before dealing with less pressing time-related issues.

> : (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?

Ah, ok, there's definitely something to that argument.  But I'm not
sure it's that easy.  Plus, while it may take less time to fix both
problems if you fix them both at the same time, it will still take
more time to fix both than it will take to just fix one.  And only one
is in danger of exploding in our faces.

Also, I suspect that 64-bit hardware will become the norm fairly soon,
and 64-bit time_t will probably fall out as a natural consequence of
that.  IOW, unlike most y2k problems, the UNIX end-of-epoch problem
may actually fix itself, to a large extent, without the need for
anything more complex than "make all".

cheers
-- 
Chris Waters             | Bill Gates: "We need room to innovate!"
cwaters@systems.DHL.COM  | 
xtifr@dsp.net (personal) | Me: "Well, that would certainly be a change."
www.dsp.net/xtifr/ (web) | 

We ought to have some sort of semi-coherent response to the Y2K issue.
Pointy-haired types are all worried about Y2K; if Linux advocates can
say:
  "Here, look at <http://www.linux.org/y2k.html>.  It shows what Y2K
   issues have been raised and dealt with..."
this defuses a whole lot of problems.

I have what links I've been able to find listed at
<http://www.hex.net/~cbbrowne/linux.html>.  It's in the last subpage of
the document...

-- 
"And 1.1.81 is officially BugFree(tm), so if you receive any bug 
reports on it, you know they are just evil lies." (By Linus Torvalds)
cbbrowne@hex.net -  <http://www.hex.net/~cbbrowne/lsf.html>

We ought to have some sort of semi-coherent response to the Y2K issue.
Pointy-haired types are all worried about Y2K; if Linux advocates can
say:
  "Here, look at <http://www.linux.org/y2k.html>.  It shows what Y2K
   issues have been raised and dealt with..."
this defuses a whole lot of problems.

I have what links I've been able to find listed at
<http://www.hex.net/~cbbrowne/linux.html>.  It's in the last subpage of
the document...

-- 
"And 1.1.81 is officially BugFree(tm), so if you receive any bug 
reports on it, you know they are just evil lies." (By Linus Torvalds)
cbbrowne@hex.net -  <http://www.hex.net/~cbbrowne/lsf.html>

Christopher Browne wrote:
> 
> We ought to have some sort of semi-coherent response to the Y2K issue.
> Pointy-haired types are all worried about Y2K; if Linux advocates can
> say:
>   "Here, look at <http://www.linux.org/y2k.html>.  It shows what Y2K
>    issues have been raised and dealt with..."
> this defuses a whole lot of problems.
> 
> I have what links I've been able to find listed at
> <http://www.hex.net/~cbbrowne/linux.html>.  It's in the last subpage of
> the document...
> 
> --
> "And 1.1.81 is officially BugFree(tm), so if you receive any bug
> reports on it, you know they are just evil lies." (By Linus Torvalds)
> cbbrowne@hex.net -  <http://www.hex.net/~cbbrowne/lsf.html>

This small thing can make a lot of difference - is caldera working on it
to get certification ?

On Mon, 16 Mar 1998 03:32:14 +0000, Nilanjan Bhowmik <nilu@worldnet.att.net> posted:
>Christopher Browne wrote:
>> 
>> We ought to have some sort of semi-coherent response to the Y2K issue.
>> Pointy-haired types are all worried about Y2K; if Linux advocates can
>> say:
>>   "Here, look at <http://www.linux.org/y2k.html>.  It shows what Y2K
>>    issues have been raised and dealt with..."
>> this defuses a whole lot of problems.
>> 
>> I have what links I've been able to find listed at
>> <http://www.hex.net/~cbbrowne/linux.html>.  It's in the last subpage of
>> the document...
>> 
>This small thing can make a lot of difference - is caldera working on it
>to get certification ?

And who do you think is the "official certifier"?

There is no obvious party that is actually legally responsible for
certifying that any particular software is "Year 2000 Compliant."

The people concerned with "certification" are Dilbertian Pointy-Haired
Managers.  They also often think that being a MCE is of some value, and that
it would actually be beneficial to outsource software development to
third-world nations.

See: <http://www.sap.com/y2000/index.htm> for a sample of what is the
typical sort of documentation of "Year 2000 Compliance."  Note that SAP AG
is selling a *pile* of software on the virtue of R/3 being a solution to the
Y2K problem.  I use the software and am reasonably confident of its
compliance; the primary issue is of systematic use of date fields that
correctly handle dates.

The point is that you can claim Y2K "compliance" so long as there is no one
able to gainsay the claim.  This is obviously safest if you have:
a) Some reasonable set of tests to verify compliance, and
b) Documentation of the tests and how they were performed.

-- 
Those who do not understand Unix are condemned to reinvent it, poorly. 	
-- Henry Spencer          <http://www.hex.net/~cbbrowne/lsf.html>
cbbrowne@hex.net - "What have you contributed to Linux today?..."

Chris Waters (cwaters@systems.dhl.com) wrote:
: gordon@sys-2-34.multitone.co.uk (Gordon Scott) writes:
: > 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?

: Ah, ok, there's definitely something to that argument.  But I'm not
: sure it's that easy.  Plus, while it may take less time to fix both
: problems if you fix them both at the same time, it will still take
: more time to fix both than it will take to just fix one.  And only one
: is in danger of exploding in our faces.

You're right, of course.

I guess I'm a little angry that it's because we (collectively)
have been putting this off so long that *now* you're right,
but if we'd addressed it early enough we wouldn't be facing a
potential problem now.

When I say we, I mean not just the software people, but 
also the sales, marketing &c. people who set priorities.

Gordon.
--
Gordon Scott
gordon@multitone.co.uk   (official)	gordon@mepsys.demon.co.uk  (backdoor)
gordon@apis.demon.co.uk  (home)		http://www.apis.demon.co.uk