SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Discuss Year 2000 Issues
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: John Mansfield who wrote (589)12/5/1997 12:29:00 PM
From: John Mansfield   of 9818
 
The '1972 fix' is not a viable solution for the vast majority of embedded systems.

From:

year2000.unt.edu ;
Topic 11 (Infrastructure, PCs, & embedded systems);
conversation 2

(you have to log in; but it is free).

------

47. Author: Peter Quinn ( peterquinn )
Date: Nov. 25 10:59 AM 1997

I have noticed that turning the clock back 28
years for embedded systems has been mentioned.
Why 28 years? Is this the earliest valid leap
year?

------------------------------------------------------------------------

48. Author: Bruce Hevner ( aceracer )
Date: Nov. 25 12:58 AM 1997

No it's because the days of the week are the same
as 2000. But this won't work with PC's. DOS
starts keeping time with 1-1-1980. Trying to
use a date earlier than 1980 will cause DOS to
display an error code of 1-4-1980. Which means
you should reset the date. Sounded SO easy
didn't it? I Wish!

------------------------------------------------------------------------

49. Author: Geoffrey Jahnke ( geoffrey )
Date: Nov. 25 3:08 PM 1997

The '1972 fix' is not a viable solution for the
vast majority of embedded systems. One of the
reasons for this was mentioned by Bruce, many
systems will not go back any further than 04 Jan
80. This has also been demonstrated in some shop
floor equipment as well as DOS systems. A major
reason that this is not a viable solution is the
mismatch with other infrastructure running
with its date in the year 2000. Between embedded
controllers this would cause a great deal of
problems. Take a process controller with the
date 01/05/2000 and a PLC with the date
01/05/1972 for instance, the PLC will attempt
to synchronize its date with the supervisory
controller. When it detects the large
discrepancy there is a good chance that PLC will
either enter into gross control failure or
enter an infinite synchronization loop . The
date mismatch would also present a problem when
an embedded controller is used in conjunction
with a business system. If a PLC in 01/05/1972
was using a network connection to log its
process into a mainframe database, this would
present quite a problem. More COBOL
programmers would be required to add the
additional date transition algorithm. Also
data printed would have a higher degree of
ambiguity. Looking back at hard-copy records,
data stamped 1/5/72 could be confused with the
data actually from 1972, where as most humans
would not confuse data time stamped 00 with data
from 1900.

GeoffJahnke
Deere&Company
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  

HomeMailHotSubjectMarksPeopleMarksKeepersSettings
Terms Of UseContact UsCopyright/IP PolicyPrivacy PolicyAbout UsFAQAdvertise on SI
© 2025 Knight Sac Media.  Data provided by Twelve Data, Alpha Vantage, and CityFALCON News