I am new to this Y2K stuff after having read an article in WIRED magazine a couple weeks ago (As a matter of fact WIRED is where I learned of this NG) and although I do agree that the potential for disaster regarding this thing is *enormous* I have one question.  Would it not be possible to just turn the clocks back on affected systems thus Buying Time if you must, until the problem can be fully eradicated once and for all. Just turn the clock, dates and all back to another year that has the same month and date scheme as the year 2000.  Sure the year would be wrong on any output but would this not be much better than a TOTAL crash of any affected systems?                                                   Kdimm

 I am new to this Y2K stuff after having read an article in WIRED magazine a couple weeks ago (As a matter of fact WIRED is where I learned of this NG) and although I do agree that the potential for disaster regarding this thing is *enormous* I have one question.  Would it not be possible to just turn the clocks back on affected systems thus Buying Time if you must, until the problem can be fully eradicated once and for all. Just turn the clock, dates and all back to another year that has the same month and date scheme as the year 2000.  Sure the year would be wrong on any output but would this not be much better than a TOTAL crash of any affected systems?                                                   Kdimm No this isn't enough except in unusual circumstances. Consider a data_base_ (say the one covering your payroll, your insurance, your bank, or whatever).  If it uses a 2 digit year date format, then the maximum date allowed is 31 Dec 1999.  Setting the clock back probably does not fix a Y2K problem as all the dates (e.g. your DOB used to calculate your insurance premiums, the next payment due date, the interest on your account, etc ), would be wrong. Additionally there are other problems - a lot of systems use 9/9/99 as a special value .  This seems will fail before 2000. Some GPS receivers will fail between 21 and 22 August 1999. Some Y2K Compliant kit will still fail between 31 Dec 1999 and 1 Jan 2000 : if for example 2 systems/products are individually Y2K compliant, but are connected together in a network - they may be in a combination - non-compliant - because of timezones, the years 1999 & 2000 will occur simultaneousy in different timezones. We have a Y2K FAQ on our site (http://www.ans2000.com), which explains the reasons behind some of the problems.  You can take a look at that if you want to read about the background

 I am new to this Y2K stuff after having read an article in WIRED magazine a couple weeks ago (As a matter of fact WIRED is where I learned of this NG) and although I do agree that the potential for disaster regarding this thing is *enormous* I have one question.  Would it not be possible to just turn the clocks back on affected systems thus Buying Time if you must, until the problem can be fully eradicated once and for all. Just turn the clock, dates and all back to another year that has the same month and date scheme as the year 2000.  Sure the year would be wrong on any output but would this not be much better than a TOTAL crash of any affected systems?                                                   Kdimm Youmight want to do a dejanews search over the past few months, and grab the FAQ - it has a nice explainantion for this. But the short answer is that this will work sometimes, and sometimes not. For example, some of my clients are hospitals with 5-10 year storage of lab & clinical info on WORM drives.  That info is brought up in date order, and some patients (cancer in most cases) have a multi-year pattern of showing up for chemo or whatever. If the dates interleave, then it becomes very icky for the doctor to get a clean report - which increases the chance of there being an Ooops . Fortunately, the systems in question are all coded Y2k compliant off the shelf But I know vendors who didn't do that. Anyway, sometimes it helps, sometimes it makes it worse.

 I am new to this Y2K stuff after having read an article in WIRED magazine a couple weeks ago (As a matter of fact WIRED is where I learned of this NG) and although I do agree that the potential for disaster regarding this thing is *enormous* I have one question.  Would it not be possible to just turn the clocks back on affected systems thus Buying Time if you must, until the problem can be fully eradicated once and for all. Just turn the clock, dates and all back to another year that has the same month and date scheme as the year 2000.  Sure the year would be wrong on any output but would this not be much better than a TOTAL crash of any affected systems?                                                   Kdimm <Groooooooooan Not another utterly clueless newbie with the same old tired 'turn back the clocks' suggestion. Oh my goodness! Maybe that's the solution! Maybe hundreds of Fortune 1000 Co's merely missed it! We're saved!!!! Not.

I am new to this Y2K stuff after having read an article in WIRED magazine a couple weeks ago (As a matter of fact WIRED is where I learned of this NG) and although I do agree that the potential for disaster regarding this thing is *enormous* I have one question. Would it not be possible to just turn the clocks back on affected systems thus Buying Time if you must, until the problem can be fully eradicated once and for all. Just turn the clock, dates and all back to another year that has the same month and date scheme as the year 2000.  Sure the year would be wrong on any output but would this not be much better than a TOTAL crash of any affected systems? This question has been asked and answered dozens of times previously. However, in summary: - Date setback will work in a limited number of situations, and it is being used. - In order to exactly match the weeks and months the setback must be 28 years (2000 = 1972). - PC _base_d systems will not function with dates prior to 1980, so the option has limited use there. - Any system that uses dates as part of the data and/or which accesses prior year's historical records would require modifying and reprocessing all of the data files as well.  Accounting and payroll systems are the classic examples but there are numerous others.  For example, one posting here some months back mentioned an accounting application which had more than 60 different date fields within the data files. - Date setback does not fix the problem, it merely postpones the work of fixing it correctly. Believe me, if simple solutions were at all practical, they would have been seized on and implemented long ago. There is no such thing as an ultimate simple solution to a great burning issue . Ron Martell     Duncan B.C.    Canada

This is actually something that can work in certain situations. The best plan I have seen is to set the clocks back 11 years so the day of week is the same, but you have to train all of your employees to subtract 11 from all dates including birthdates, and all reports will appear 11 years old. There are multiple problems if you have to export or import data to other systems, and you must also age all current data 11 years. Kind of complicated but could work for some systems. This does not address imbedded chip issues, but it is a possible solution, but I don't expect many to use it, since very few companies are islands.