<nettime> Y2K stuff

[t byfield <tbyfield@panix.com>]

[for some reason, the nettime inbox started to fill up yesterday with 
 stuff about the millennium: Y2K stuff, anticipatory bank runs, texts
 about memory at the 'end of history,' remarks about when exactly the
 millennium begins etc. anyway, rather than reproduce this mysterious
 trend in everyone else's inboxes, i thought i'd (a) dole it out, bit
 by bit, and (b) inaugurate it with some Facts. for those who haven't
 spent much time studying Y1K, there are some very interesting paral-
 lels--for example, disagreements over which specific event would get
 the anniversary (John the Baptist's ministry, Jesus' birth, or maybe
 his death, etc.), differences from area to area in reckoning exactly
 which year it actually was, and so on. upshot: the 'year 1000' span-
 ned a few decades: it was a zeitgeist, not an event. and, of course,
 there was much debate as to what would happen and why: would the end
 come in a thunderclap because of the accumulated mass of human sins,
 or would it be a process of redemption that would last 1000 years...
 anyway, so here we see that there's not one problem, but many, which
 may or may not conspire to bring about...well, no one knows. person-
 ally, i reckon this Y2K stuff occurs on two levels: the technical or
 material level (malfunction, automated consequence), and the symbol-
 ic level--the cultural values that are assigned to technical issues,
 the way these values play out across the topological fabric of soci-
 ety. maybe societies begin to shred like a flag in a hurricane, may-
 be it just drifts, like seaweed in a tidal wave. or maybe nothing at
 all, just a bunch of stupid little hassles--not that cultural values
 require a substantial 'objective' basis, mind you. how about: Y2K as
 a referendum on the alienation we effect by 'embedding' social rela-
 tions in inflexible procedures? sort of like the 'thank you' printed
 on a nakpin in a restaurant: no need to be polite anymore, can't you
 read, asshole? but bigger and meaner. anyway, read on... cheers-ted]

 <excerpted from> 
> http://webserv1.startribune.com/cgi-bin/stOnLine/article?thisSlug=Y2K13 
> 
> Published Sunday, September 13, 1998 
> 
> Jan. 1, 2000, isn't only 'doomsdate'
> 
> Steve Woodward / Newhouse News Service
 <...>
> Jan. 1, 1999: The one-year-look-ahead problem
> 
> Not every computer counts forward like you and me. Some look down the 
> road one entire year and count backward to determine the date. (Please 
> don't ask why.) On Jan. 1, 1999, some will look forward one year and see 
> "00." Like humans, the computers may balk at having to count backward 
> from 00.
> 
> Jan. 1, 1999, to Dec. 31, 2002: The euro currency problem
> 
> We all know that the year 2000 problem is the biggest software project 
> in history. But many Americans are unaware that programmers throughout 
> the world are also at work on the second biggest software project in 
> history: converting the currencies of 11 European nations into a single 
> currency called the euro.
> 
> Banks and financial institutions will begin transacting business in 
> euros on Jan. 1, 1999, although the actual bank notes won't be issued 
> until Jan. 1, 2001. The introduction of the euro is to continue through 
> the year 2002.
> 
> There's no direct link between the euro project and the Y2K project, but 
> the massive size of the simultaneous projects will soon take most of the 
> world's available programmers.
> 
> Aug. 21, 1999: The GPS rollover problem
> 
> The world's 24 global positioning satellites record time by counting the 
> weeks that have passed since their launch in 1980. The weeks fill up a 
> counter much like the odometer on your car. But like your odometer, the 
> counter rolls over to 0000 when it's full. At midnight on Aug. 21, 1999, 
> the counter will be full. Equipment that uses the GPS signals may 
> malfunction.
> 
> Sept. 9, 1999: The 9999 end-of-file problem
> 
> Many computers have been programmed to recognize 9999 as an 
> "end-of-file" command. Perhaps some computers will conclude, quite 
> logically, that a date of 9/9/99 means it's the end of all time.
> 
> Oct. 1, 1999: The federal fiscal year 2000 problem
> 
> Big Daddy rolls its clock forward Oct. 1, 1999. As of that date, the 
> federal government officially enters its 2000 budget year. Every federal 
> function will be affected, from defense to Medicare to payments on the 
> federal debt.
> 
> Jan. 4, 2000: The first-working-day-of-the-year problem
> 
> Year 2000 begins on a Saturday. Corporate America will switch on most of 
> its desktop computers Tuesday, Jan. 4, after a long holiday weekend. 
> Boot up and hang on to your morning mochas.
> 
> Feb. 29, 2000: The Year 2000 leap year problem, Part I
> 
> Most programmers know the rules for calculating leap years: Any year 
> evenly divisible by four is a leap year, except years that also are 
> divisible by 100. So 1996 is a leap year, but 2000 isn't -- er, right? 
> Well, there's a third, lesser-known rule that cancels the first two: Any 
> year divisible by 400 is a leap year, including -- you guessed it -- 
> 2000. The question is: How many programmers know that rule?
> 
> Dec. 31, 2000: The Year 2000 leap year problem, Part II
> 
> Some computers work by counting the number of days in the year. If they 
> aren't programmed to know that 2000 is a leap year, the machines will be 
> bewildered when they reach Dec. 31, 2000, the seemingly impossible 366th 
> day of the year.
> 
> Sept. 8, 2001: The Unix end-of-file problem
> 
> Unix is the "other" major operating system, a set of instructions that, 
> like Windows, DOS and MacOS, run the basic functions of a computer. Unix 
> powers many commercial and Internet computers. Unix tells time 
> differently, which means that it does not have a year 2000 problem. 
> Unfortunately, it does have a Sept. 8, 2001, problem. In Unix language, 
> that date is represented by the number 999,999,999 -- the same number 
> that some Unix applications use to denote the end of a file.
> 
> Circa 2025: The U.S. telephone number problem
> 
> By the year 2025 or so, the United States will simply run out of 
> available seven-digit telephone numbers and area codes. Telephone 
> companies will have to add digits or revamp the numbering system. That, 
> in turn, will force software programmers to overhaul every piece of 
> software that uses phone numbers, plus all databases and archives that 
> store phone numbers.
> 
> Jan. 19, 2038: The other Unix problem
> 
> The Unix operating system tells time by counting the number of seconds 
> elapsed since Jan. 1, 1970. But like your odometer, there are only so 
> many places on its counter. At seven seconds past 3:14 a.m. on Jan. 19, 
> 2038, the counters on every Unix computer in the world will be full and 
> will roll over to "0." Many computers will assume it's either Jan. 1, 
> 1970, all over again (who wants to relive the '70s?) or that it's the 
> end of the world (which may be a better alternative than the preceding).
> 
> Circa 2050 to 2075: The Social Security number problem
> 
> By 2075, the United States will have exhausted the 1 billion unique 
> Social Security numbers possible under its nine-digit numbering system. 
> Year 2000 expert Capers Jones suggests that the nation must be prepared 
> by 2050 to expand or replace the many software applications that depend 
> on those numbers.
---
#  distributed via nettime-l : no commercial use without permission
#  <nettime> is a closed moderated mailinglist for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@desk.nl and "info nettime-l" in the msg body
#  URL: http://www.desk.nl/~nettime/  contact: nettime-owner@desk.nl