Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 -- Ignore unavailable to you. Want to Upgrade?

To: Cheeky Kid who wrote (1583)	5/3/1998 1:38:00 PM
From: John Mansfield	Read Replies (1) \| Respond to of 9818

Failing systems that did not use a date function ' K.M., <Would you post an example of the type of Embedded failure you are looking at please.> This email I received from Roleigh Martin, an expert in this area, might answer your question. "I was a little disappointed in that one spokesman who said they had nothing to worry in their hardware, because their devices do not work at the date level. That showed ignorance of how these devices sometimes work. There are plenty of electronic devices who only CARE about millisecond intervals, but whose electronics for calculating the millisecond difference pulls a time value from a computer clock that might look like this to the software: YYMMDDHHMMSSTHK where YY=2 digit year MM=2 digit month DD=2 digit day HH=2 digit hour (military time) SS=2 digit seconds T= 1 digit tenths of a second H= 1 digit hundredths of a second K= 1 digit thousandths of a second and the device figures out the gap in time (in milliseconds from) invoking a built-in function that sends two values of YYMMDDHHMMSSTHK, called YYMMDDHHMMSSTHK[present], YYMMDDHHMMSSTHK[past] and the device always assumes that YYMMDDHHMMSSTHK[present] minus YYMMDDHHMMSSTHK[past] = positive number difference However the above assumption will fail in 1/1/2000 if the past value is before 1/1/2000. So anytime I hear a spokesman say, there is no worry because we only deal in milliseconds, etc., I consider that spokesman ignorant of what is the nature of the beast. NOW, NOT ALL DEVICES WORK THIS WAY -- some only deal in ticks, and represent a past tick with a positive integer, and a future tick with a larger integer, and true "time" is never dealt with -- those devices will have no problems. Also devices such as the above that accomodate the century rollover will work. Those devices that represent the year as 4 digits will work. And in some cases, some devices will not encounter such subtractions that lead to negative numbers, because they might not be "doing anything" on the rollover and their history span might be only "seconds or minutes ago". But some devices will fail and have been proven to fail." Roleigh Martin ourworld.compuserve.com From: Message 3255685

To: Cheeky Kid who wrote (1583)	5/4/1998 9:21:00 AM
From: Jerry Heidtke	Respond to of 9818

>Paul, I think some people may have learned something by reading >those posts. The common dominator was if a product didn't use a >date field for any function it won't be affected by Y2K. Yeah, I've seen those statements by vendors, that product xyz "has no clock function, and therefore no Y2K problems." I know of several cases where the vendors are lying. The product supposedly has no clock function, yet when you go to install/ configure the product, the first item on the screen is to set the date and time. I also know of cases where the vendor used to claim a product had no Y2K problems, and have since found problems and had to issue fixes. So, what's the value of all these vendor statements? About zero. You still have to inventory all your systems, decide which are most critical to your business or organizations, and then test those. For the non-critical ones, relying on vendor assurances may be acceptable. But to rely on vendor statements to assess Y2K problems in mission-critical functions is just negligence. Is this what you are proposing? Jerry