Time: Sun Sep 21 23:54:49 1997
	by usr05.primenet.com (8.8.5/8.8.5) with SMTP id RAA28290;
	Sun, 21 Sep 1997 17:06:04 -0700 (MST)
Date: Sun, 21 Sep 1997 17:05:45 -0700
To: jus-dare@freedom.by.net
From: Paul Andrew Mitchell [address in tool bar]
Subject: SLS: The Date, in Confusing Terms

The problem, briefly, is to "model" the
passage of "time" with "numbers."

There are an infinite number of systems
of representation, because there are an
infinite number of representations, e.g.
an infinite number of radix bases.

If a particular storage decision by a programmer
results in an "older" date by "adding" time,
then the representation is an error, within
that "range" of numbers.  For example, the
earth is, indeed, flat within a pre-defined
range of the earth's curvature, e.g. concrete
slabs for homes are flat, within the range of 
normal instruments (e.g. carpenter's levels).

If the program computes the following result:

     99 + 1 = 00

then, it is obviously an error, IF the programmer
intended the result to be 100 (in decimal).

But, I know of similar calculations in which
such a "strange" result is not only correct,
but intended.  Take, for example, a circular
queue.  One application of such a queue occurs
when a long, contiguous stretch of RAM must
be written to disk, one "page," or disk "sector,"
at a time.  The page addresses cycle from 0 thru 511
(using a starting address of 0), then they re-cycle
after the "page" is written to disk.  So, here is
a Fortran expression to map the RAM address into
the "page" address:


"MOD" is the Fortran function for "modulus."  
If RAMADD equals 512, then

     MOD(512,512)  = 0  

Think of this function as the "remainder," after
integer division is accomplished with the modulus.
It is NOT the quotient;  it is the remainder.
The quotient, obviously, is the interger 1,
using integer arithmetic.

Likewise, if RAMADD equals 1024, THEN

     the quotient =
     1024/512 = 2, but

     the remainer =
     MOD(1024,512) =  0 also

Intervening values of RAMADD result in the following
obvious sequence:

     MOD(513,512)  =  1
     MOD(514,512)  =  2
     MOD(515,512)  =  3
     MOD(1025,512) =  1
     MOD(1026,512) =  2
     MOD(1027,512) =  3 and so on.

As a homework exercise, you might fill out the
rightmost two columns in the following table:

            0         512
            1         512        
            2         512
            3         512
            4         512
          512         512
          513         512  etc.

So, there are specific storage representations,
and specific algorithms, which intend to produce 
the following correct result:

     + 1

as in the case of a queue with 100 entries,
or "cells," each with separate, unique "addresses"
ranging from 0 thru 99.  Then, in this sequence,
100 maps into cell 0, so we would WANT a result
of 0 if we added 1 + 99.

However, in date computations, this might produce
the correct result, and it might not.

It all depends on the nature of the application,
the storage representation, and the range of 
values which are factored, and then stored, into
these storage representations.

In practical terms, so many different programmers
have worked on so many different computer codes, 
what we are seeing, I believe, is the management 
nightmare that occurs when the authors of certain 
programs are now long-gone, and nobody is able to find, 
and correct, ALL the places in these myriad of codes
where such errors might occur.  In many ways, this
happens all the time in the computer industry, in a
multiplicity of other ways.  FAT16 yielded to FAT32;
16-bit addressing yielded to 32-bit addressing, 
soon to yield to 64-bit addressing;  and so on.
So, the Y2k problem is by no means a rare or isolated
event in the computer world.

The key, I argue, is to plan and design systems to
survive until you retire.  Then, it is someone's
headache to determine whether your approach will
survive while you are away fishing, or whether it
must be re-written entirely, or patched.

You can tell that Bill Gates opted to write his
own memory management for Windows 3.1, even though
far superior memory management schemes had already
been available on the market since the legendary
VAX 11-780 first made the scene, circa 1980, and
even before, in the Prime 400 super minicomputer.
He tried to re-invent the wheel, and the wheel
almost ran over him (almost).

The Internal Revenue Service is dying for a whole
lot of other reasons, not just their Y2k problem;
even if they were to fix each and every error
in their myriad of codes which now run on outdated
COBOL batch machines, their fraudulent foundation is
crumbling into a zillion pieces, even as we read
and write these words (in binary digits) all across 
the Internet.  If the Y2k problem helps them crumble
just a little bit faster, I say, LET 'EM CRUMBLE!

They richly deserve it, after taking bread from the
mouths of oh so many of our children, and using
that money to build HUGE weapons factories like
the Kama River project in the Soviet Union, to bribe
judges and prosecutors, and no doubt to grease the
flow of narcotics into this country, FOB the Golden
Triangle (Thailand, Burma, Laos), for the benefit of
foreign banks and their alien owners.   

My 2 cents :)

/s/ Paul Mitchell

At 06:43 PM 9/21/97 +0000, you wrote:
>*Jus Dare*
>The Date, in Confusing Terms
>[Ugh! I never liked math... If the fields for entry are defined as AN 
>(alphanumeric) then you get 256 opportunities for entry (in any 8 bit 
>system) insted of just 10 (0-9) in a numeric only field. This gives 
>you 65,536 possibilities for 2 digits, instead of only 100. I *think* 
>that is part of Bruce's message below...  - Dave]
>From: excalibur25@juno.com (Bruce Chesley)
>Date: Sun, 21 Sep 1997 10:31:24 EDT
>Subject: Re: [jus-dare]  Y2k - Feb. 30 ?
>     Thank you Dave for giving me a semi sleepless night;-)  
>     We must step back and look at the date identification, storage,
>CALCULATION and reporting more completely.  The Standard Year (YYYY) is
>12 months (MM), depending upon month from 28 - 31 days (DD), totaling 365
>days (DDD), 6 hours (HH), MM minutes, SS seconds and NN nanoseconds. 
>Every YYYY divided by 4 with 0 remainder is a leap year, giving us a
>February 29th..  The MMSSNNs continue to accumulate until - TADA - a
>February 30th occurs to keep the Gregorian Calendar "accurate".  This
>happens every YYYY divided by, if I remember correctly, 400, with 0
>remainder.  As 2000 / 400 = 5 with 0 remainder, a potential 2/30 could
>need to be correctly accounted for.  Correctly calculating the February
>days is enormously important in the big picture, FOR EVERY DATE
>CALCULATION DEPENDENT ISSUE.  Interest being the obvious.  Insurance
>policies, hourly payroll, vacation, retirement, manufacturing days,
>ordering, payables, receivables, shipping, inventory, . . . 
>     USA uses MMDDYY, Canada uses DDMMYY and other countries use YYMMDD
>as their standard date formats.  In the early 1970s, the standard that I
>used for storing and calculating dates was YYYYMMDD in a signed numeric
>external decimal or a faster calculating signed packed numeric field. 
>This format made for an easily understandable, left to right, date
>calculation.  The proper standard date format would be used for printing.
>     I quick solution:  If the date is stored as 6 external decimal
>numeric positions , the corrected 8 can be stored in 5 signed packed
>numeric positions in the same 6 position field, thus eliminating the need
>to expand field size, record length, file size, all current and
>generation files. You gain a faster calculation in the process -
>critically important where repetitive date calculations are done with
>large files.  If the date is defined in 6 alphanumeric (AN) positions, it
>is program language dependent how you would convert the 6 AN into 6
>numeric as an intermediary step.  This greatly reduces the effort to
>solve the Y2K.  
>Bruce Chesley,
>New England Field Representative,
>Jews for the Preservation of Firearms Ownership
>  *  *  *  *  *
>*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.]


Return to Table of Contents for

Supreme Law School:   E-mail