My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
Agenda Packets - 1999/02/01
MoundsView
>
Commissions
>
City Council
>
Agenda Packets
>
1990-1999
>
1999
>
Agenda Packets - 1999/02/01
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
1/28/2025 4:46:12 PM
Creation date
6/14/2018 6:01:45 AM
Metadata
Fields
Template:
MV Commission Documents
Commission Name
City Council
Commission Doc Type
Agenda Packets
MEETINGDATE
2/1/1999
Supplemental fields
City Council Document Type
City Council Packets
Date
2/1/1999
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
113
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
YEAR 2000 PROBLEM <br /> Encryption:It is possible to use binary arithmetic to compress dates expressed with four-digit <br /> years to occupy the same storage space as those with two-digit years. This approach gives the <br /> permanence of full date conversion without the need for more storage capacity, but it requires <br /> extensive reprogramming and is not intuitive. <br /> Encapsulation:The Gregorian calendar has an interesting quirk-- it repeats every 28 years. <br /> Since the Y2K problem can be seen as a problem related to six-digit dates at the turn of the <br /> century, encapsulation simply resets to 28 years earlier. The computer and its programs do <br /> calculations based on a 20th century date and then add the 28 years back in for display purposes. <br /> This approach gives a quick fix for situations where source code is lost or time has run out. But it <br /> does not account for religious holidays that don't follow the Gregorian calendar. In the end,it may <br /> be useful only in embedded process controllers in which the actual year is not important but day of <br /> the week is very important. <br /> A strategy for putting the appropriate technical fixes in place might look like this: <br /> Inventory all automated systems and equipment; <br /> test to determine which will be compliant,and which will not; <br /> prioritize the results; <br /> find out what remedies to apply; <br /> determine which applications can be fixed on time;and <br /> develop contingency plans for those that can't be fixed on time. <br /> But doing that is complicated by two factors. <br /> One is that there are many related areas to find and fix. In numerous cases, application software was <br /> developed on a custom basis, or at least heavily customized,to handle local government business practices. <br /> These custom applications can be difficult to maintain,and some are too old to change. Even a medium- <br /> sized local government or business could have millions of lines of program code, nearly any of which could <br /> use dates. Invalid date comparisons could crop up in programs,training,embedded processors,and data. <br /> Beyond the computer hardware and software,too,there are all those other systems and devices that are <br /> controlled by microchips. <br /> The other complicating factor is time. It will take time to make all the necessary changes. The inventory <br /> alone could take six to nine months for a medium-size organization and longer, up to twice as long,for a <br /> large one,according to some experts. And that's only the computers and software. Figure another three <br /> months to inventory all equipment that uses embedded chips. Once the code that needs fixing is identi- <br /> fied, maybe 70 to 80 percent can be updated automatically. The rest will have to be read, a line of code at <br /> a time, by programmers, and manually changed. At an average rate of 3,000 lines of code a day,that is no <br /> quick job either. <br /> -6- <br />
The URL can be used to link to this page
Your browser does not support the video tag.