[TheGuide Logo]






About Raj

Y-?what?-K Impact of Y2K and related issues
by Bruce Gingery

(Note: Most of the write-ups about Y2K are focused on US centric type issues. Some information about issues that India might face has been given Y2K and You. But many serious problems may arise from utilities which depends on electronics. One serious matter is that of nuclear power plants that we have in India. TheGuide has not seen much assurance about these and other infrastructural issues. Would appreciate knowing any information regarding such problems. Send Feedback.

There are dangerous trojans maquerading as y2k fixes and testers. Also that most non-Microsoft updates for Windows systems are DOS specific and can damage UNIX systems installed on PCs, if they are attempted to be used - especially those which run from a bootable diskette.)

Everybody's been talking about Y2k, and we're down to 8 days from the roll-over to the _start_ of the year 2000, and 373 days to the start of a new mellenium as it's calendared on the (current) Gregorian calendar.

Things to watch:
  • See the moon on Wednesday of next week (22nd). It'll be the "closest" "biggest" and brightest (as a combination) in 133 years! But really, this is about calendars and dates, and even though the moon is intrinsic in that, let me get back to my initial intent.

  • First it's been reported that _some_ old PC's will get garbled in their hardware clock and BIOS upon attempt to reboot or power-up on (or after?) Jan 1, and maybe after. This should affect only the BIOS - so a replacement of a motherboard (or BIOS chip) may fix it. Don't panic - at WORST, you'll likley just have to put your Hard Drive in another computer to get at your data. Good time to know your neighbors.

  • This (above) is only expected to affect PCs running DOS and/or Windows, but according to testimony leading up to Microsoft being declared a monopoly, that MAY be as much as 90% of the computers in the world.

  • Uncorrected programs running on major mainframes, such as those written years ago in COBOL using "PICTURE 99" to store a 2-digit date, MAY roll over to Jan 1, 1900 instead of Jan 1, 2000. Similarly those which improperly use "conversions" inserting a "19" instead of adding 1900 may show a strange year of 1910 or 19100. This could happen in spreadsheets and the like, and even appear on bills, computer-printed checks, and so forth.

  • It's been reported that Windows will have the wrong date on Feb 29, 2000 (all versions). This probably affects the underlying DOS, as well. Even if you've checked your computer, don't wait for Feb to doublecheck your software vendor. This may also affect future-date calculations in some software.

  • See Microsoft's Y2k site for directions on what YOU should do with YOUR version if you run Windows. (Preferably within the next few days). ALL versions of Windows (as of just over a week ago) either indicate "manual intervention required" or just plain not-compliant for Y2K. That manual intervention MAY include the need to download and install software or download and install patches to software.

  • If something you download is small enough, keep a copy of it on diskette - your neighbor might need it, or you might later have to "reinstall windows". Be sure to clearly mark the diskette.

  • Old (and perhaps forgotten) viruses may re-activate any time during the year 2000. Especially on Feb 29th and April 1st. Make sure your anti-virus software is up to date (if you're using a system that _needs_ such software).

  • Microsoft has a complete compendium for _their_software and Y2k.

  • For non-Microsoft applications/OS running on your machine - see the appropriate vendor or support web site.

  • Sorry - I forgot to check on Microsoft software running on Macs, and Microsoft has an entry for every "package" they produce - I only checked on the underlying windows.

  • Software hacked to "cut over" to a 2010 rollover will declare anyone born prior to December 1911 to have not yet been born (and similar date errors). If you are over 78, or know someone who is, watch closely that you/they don't have something like a February Social Security or other Retirement check come up missing. The January one will PROBABLY be okay, printed in December.

  • Your VCR, Microwave, or other things with a low-grade clock in them that also checks days or days-of-the-week may also fail. Set 'em to 1972 if you can. The year may read wrong but the days will line up, and it'll give you a few more years good use. This is not expected to work with PCs that presume that the lowest possible year is 1980 - but you can try with specific sofware packages.

  • Do you have anything on a mechanical or electro-mechanical timelock that you may have overlooked? Perhaps a "safe" or "vault"? It should be analyzed for both Jan 1 and Feb 29.

  • Also, this is very US centric in its predictions, as far as "panic" being the greatest danger. There may indeed be infrastructures in other countries that are much farther from being ready to handle emergencies than the US. Yet, the odd side-effects of Y2k preparation are quite accurate, like people over 78 not being born yet, or the year 19100 coming up where 2000 belongs.

Next time(s) around....

2005 See 2010 below - it's probable that some only used 5 years.
2006 See 2010 below - some used 6 years
2007 See 2010 below - some used 7 years
2008 See 2010 below - some used 8 years
2009 See 2010 below - some used 9 years.

  • 2010 A federal guideline in the US suggested putting off Y2k for about 10 years, by altering the "presumed century" on 2-byte year fields. This will affect databases, and could be easily overlooked. I forget if this was the budget office for the administration or for congress, but it was one of them making this recommendation without even INSISTING that such "hacks" be carefully recorded.

  • 2011 and up - see above for 2010. Some used MORE than 10 years - generally not over 15 or 20.

  • 2038 On Tuesday, January 19, 2038 at 03:14:08 Coordinated Universal Time (also known as UTC, UT, or historically and often as GMT) most C libraries (and that is what supports MOST systems) as well as most UNIX systems will wrap from a positive 32-bit signed integer to a negative. Hence uncorrected software will display Friday, December 13, 1901 20:45:42 GMT.

  • This is because this 32-bit value is a seconds count from the "base date" of January 1, 1970 0:00:00 GMT. Conversions TO "time()" values will sweep around the world on that day as "local time" hits uninterpretable values. It is expected that most such libraries will be corrected to 64-bit long before that time which moves this problem well toward the bottom of this list. The current format only allows for this plus-or-minus 24,855 days (2,147,483,647 seconds) from that Jan 1, 1970 timestamp.

  • 2039 The Hebrew calendar will roll over to 5800..

  • The Muslim calendar (which uses a 354 day year of six 29-day months and six 30-day months cycles by 11 days per year and) isn't even used for secular purposes in Muslem countries.

  • The Aztecs used several different calendars at the same time. One of them had a year that consisted of eighteen months of 20 days plus 5 days not within a month. I don't THINK anyone's using the Aztec calendars today.

  • The People's Republic of China also uses the Gregorian calendar, although they have an extra (leap) month every 19 years in their ceremonial calendar.

  • 2048 The MacIntosh base date is ten years later than the UNIX (and usual C library) base date. While tracking is not identical on the Mac, software ported from other systems may merely be adjusting the base date by 10 years. Frankly, I don't recall if it's also off by 7 hours (PST instead of GMT) or not.

  • 2070 Because the C library and UNIX base date is January 1, 1970, and the initial ARPA net operations started shortly after that, there's a lot of software that presumes any two-digit year of 69 or below is in the 2000's, but 70's and above are in the 1900's. This includes MOST E-Mail software.

  • 2098 7-bit years will expire if counted from 1970 - this is the largest SIGNED value that can be stored in one byte.

  • 2216 8-bit years will expire if counted from 1970 - this is the largest UNSIGNED value that can be stored in one byte.

  • 2239 The Hebrew calendar will roll over to the year 6000.

  • 2482 9-bit years will expire if counted from 1970

  • 2800 The Gregorian calendar (which is a FULL day slow in 20,000 years) will depart from the Eastern Orthodox calendar, which is one day slow in 45,000 years. 10-bit offsets from 1970 will also expire soon.

  • 4000 Gregorian Calendar based software that doesn't allow for the "evenly divisble by 4000 is not leap year" rule will add an extra non-existant February 29th.

  • 20,004 Gregorian Calendar will have to drop Leap Year or will be STILL be off a day.

  • 45,000 The Eastern Orthodox calendar becomes a day slow - the Patriarch of Istanbul will have to decide what to do.

  • Now, I may have missed a few things, hopefully not. Rumors are rampant. The greatest dangers are from panic - not actual events.

Bruce Gingery

Copyright 1999 Dr. Raj Mehta. All rights reserved.