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: PAGEADD = MOD(RAMADD,512) "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: INTEGER INTEGER INTEGER INTEGER DIVIDEND MODULUS QUOTIENT REMAINER 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: 99 + 1 --- 00 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 http://supremelaw.com 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**