Time: Sun Sep 21 08:39:01 1997
	by primenet.com (8.8.5/8.8.5) with ESMTP id IAA07820;
	Sun, 21 Sep 1997 08:39:18 -0700 (MST)
	id LAA09544; Sun, 21 Sep 1997 11:37:17 -0400 (EDT)
	id LAA09508; Sun, 21 Sep 1997 11:37:08 -0400 (EDT)
	id AA16649; Sun, 21 Sep 1997 11:37:05 -0400
	by usr09.primenet.com (8.8.5/8.8.5) with SMTP id IAA08150;
	Sun, 21 Sep 1997 08:32:21 -0700 (MST)
Date: Sun, 21 Sep 1997 08:32:05 -0700
To: jus-dare@freedom.by.net
From: Paul Andrew Mitchell [address in tool bar]
Subject: SNET: Y2k, a Scam?  Not necessarily.


->  SearchNet's   SNETNEWS   Mailing List

I don't think it is a scam.  It is just that
many programmers are not adequately trained
to model "time" in the proper linear sequence.

The proper way to do it, in a numerical language
like Fortran, is to store time as a huge double-
or quad-precision number, e.g.

    19970921.125 etc.

This number represents the year 1997, ninth month,
twenty-first day, 12.5% of 24 hours since midnight,
and so on.  Or, the programmer can use a base "day"
and derive mm/dd/yy/hh:mm:ss using simple arithmetic.

In double-precision (64 bits), the mantissa can 
preserve 15 decimal digits of precision, so there are
plenty of bits to maintain the correct time.  Remember,
the decimal place "floats", so it is the decimal precision
in which we are interested here.

Thus, quad-precision (128 bits) is overkill, unless the
programmer is trying to preserve microseconds
and centuries precisely in the same number.

Clearly, there are quite a large number of variations
which a programmer might choose to implement, all of
them slightly different from the next.

E.g., another way to do it, if you not interested in 
splitting seconds, is to store time in the same
way that a digital clock stores time, in discrete
intervals:

   19970921081135

This number is a 64-bit integer which represents
the year 1997, ninth month, twenty-first day, 
eighth hour, eleventh minute, thirty-fifth second.
You need a 64-bit integer, because 32-bit integers
can only count up to 4 billion.

Now, here is the rub:  if a programmer chooses
some variation on these last 2 methods, but fails to
keep the century, the storage allocated to this
number would appear like this:

      970921081135

This works fine, within the present century, 
but at midnight on the night of December 31, 1999,
here is what happens:

      99
     + 1
     ---
      00  because the programmer has not allocated
          space for the century.

This is particularly nasty with COBOL programs
which are designed to compute formatted digits
(not binary digits) as their primary results.

So, it is not a hoax;  it is just that every program
which attempts to compute and store dates, probably
has its own unique way of doing it.  Some programs
are going to work fine, while others are going to 
roll back to the year zero in this century, with more
or less serious consequences.  If IRS is heavily 
invested in COBOL, which they have been for decades,
their databases are going to melt down, as their
slippers turn to glass, and their limousines turn 
to pumpkins.

There you have it, from a computer systems consultant
for 26+ years.

/s/ Paul Mitchell
http://supremelaw.com



At 09:18 AM 9/21/97 +0000, you wrote:
>
>*Jus Dare*
>Y2k, a Scam
>
>[I am pleased that Harold sends this post. It would not be an issue 
>if everyone agreed...  Like Harold, my personal understanding is 
>built solely on the opinions of others, mix with what I hope is 
>logic. Here's one for all the nay-sayers. It is not that I won't 
>print the "other side." This is the first post submitted *from* the 
>other side. Incidentally, XfreedomX is correct: there is economics 
>involved on both sides, so the posts must be weighted accordingly.  
> - Dave]
>
>From: "Harold Thomas" <harold@halcyon.com>
>Subject: Re: piml] Software Developers Relief Act of 2000
>
>Steve,
>
>Many thanks for passing along this info.  Personally I have about 
>ZERO computer expertise, and there seem to be various people with 
>seemingly considerable experience who are absolutely convinced there 
>is a major disaster brewing -- a couple of whom are not offering any 
>services or software for sale and whom I'm sure believe what 
>they're saying is 100% true.  
>
>Your input as one active in the profession at a very respectable and 
>credible level is important.  It is also good of you to put it on the 
>line by offering your personal contact info.
>
>I'll post widely.  Thanks again.
>
>Harold Thomas
>
>
>> From:          XFreedomsX@aol.com
>> Date:          Sat, 20 Sep 1997 18:10:47 -0400 (EDT)
>> To:            harold@halcyon.com, piml@mars.galstar.com
>> Cc:            Steven1997@aol.com
>> Subject:       piml] Software Developers Relief Act of 2000
>
>> Thanks for your post on the forecasted meltdown of 1/1/2000.  Having spent
>> ten years in software (most recently as an employee/consultant of Oracle),
>> designing, developing and mananging projects, I can tell you that this
whole
>> Bug 2000 thing is a scam, designed to line the pockets of software
companies
>> and consultants.  
>> 
>> Though I'm truly disgusted with the idea of ripping off customers, the
>> perpetrators are pulling off the perfect scam.  Once the customer buys the
>> false premise of a ticking time bomb, in effect, the software company has a
>> gun to their head.  Sick but true.  I will offer a chance to prove what
>> foolishness this is.  My company will do the job for 25% of what any large
>> systems house would charge.  The algortithm is simple:
>> 
>> (1) simply identify every instance of "date", whether it be a database
field
>> or hard coded, and then,
>> 
>> (2) develop a translation routine (a.k.a. function or procedure) which is
>> automatically called upon at each point in the program where date is
>> encountered,
>> 
>> (3) ensure that mathmatical operations can be performed on dates, in the
same
>> fashion that they were before, by adding the "Julian" value of one
century to
>> the representation for 1900, in each instance of date computations.
>> 
>> Anybody want to save a few million bucks? Know any corporate execs who are
>> holding their ankles these days? Before their blood spills, you might
>> consider having them get a second opinion.  The biggest disaster of 1/1/
2000
>> will be the invoices which corporate America is going to get slammed
with, as
>> the consultants go party.
>> 
>> Anybody can call me at Softel, Incorporated (847) 559-9600.
>> 
>> Steve Wallace
>> 
>
>  *  *  *  *  *
>
>*Jus Dare* means "to give or to make the law."
>This list deals with the perversion of the Supreme Court.
>
>To subscribe, send the message "add yourmailname.server"
>in the body of a message to jus-dare-request@freedom.by.net
>or contact Dave Delany <freedom@hancock.net>
>
>Visit us on the web: http://hancock.net/~freedom
>
>Dave Delany's Freedom House  PO Box 212  Conklin  NY  13748
>*Jus Dare* is a service of Hearthside Family Publications.
>
>

========================================================================
Paul Andrew Mitchell                 : Counselor at Law, federal witness
B.A., Political Science, UCLA;  M.S., Public Administration, U.C. Irvine

tel:     (520) 320-1514: machine; fax: (520) 320-1256: 24-hour/day-night
email:   [address in tool bar]       : using Eudora Pro 3.0.3 on 586 CPU
website: http://www.supremelaw.com   : visit the Supreme Law Library now
ship to: c/o 2509 N. Campbell, #1776 : this is free speech,  at its best
             Tucson, Arizona state   : state zone,  not the federal zone
             Postal Zone 85719/tdc   : USPS delays first class  w/o this

As agents of the Most High, we came here to establish justice.  We shall
not leave, until our mission is accomplished and justice reigns eternal.
========================================================================
[This text formatted on-screen in Courier 11, non-proportional spacing.]

-> Send "subscribe   snetnews " to majordomo@world.std.com
->  Posted by: Paul Andrew Mitchell [address in tool bar]


      


Return to Table of Contents for

Supreme Law School:   E-mail