Do you remember Y2K?
- Thread starter D2Cat
- Start date
GreensvilleJay
Well-known member
Equipment
BX23-S,57 A-C D-14,58 A-C D-14, 57 A-C D-14,tiller,cults,Millcreek 25G spreader,
hmm. For us it was a real issue that cost the company hundreds of thousands of dollars based on a bug inside a chip from one supplier.
I'm curious..
Which 'chip' ? During that time(no pun intended) I designed/built custon energy controllers using Intel and Dallas Semi parts.All it took was an easy night of code cutting to make the 'patch'. Needed another when 'they' decided to change when DST would trigger.
I'm curious..
Which 'chip' ? During that time(no pun intended) I designed/built custon energy controllers using Intel and Dallas Semi parts.All it took was an easy night of code cutting to make the 'patch'. Needed another when 'they' decided to change when DST would trigger.
IIRC it was an ASIC from Fairchild. I can't be sure, I was in sales at the time.
Magicman
Well-known member
Lifetime Member
Equipment
M4900 Utility Special 4WD e/w FEL & 1530 John Deere "Traveling Man"
And then there is the Unix date rollover problem coming up on January19, 2038. Will be interesting to see if all the Unix systems still running then get patched in time. If past experience prevails, they won't.
Don't know if I'll even be around then.
Don't know if I'll even be around then.
Neither do I. I remember the Trade Center more than anything and how we as a country in general, have a very short memory.
Magicman
Well-known member
Lifetime Member
Equipment
M4900 Utility Special 4WD e/w FEL & 1530 John Deere "Traveling Man"
GreensvilleJay
Well-known member
Equipment
BX23-S,57 A-C D-14,58 A-C D-14, 57 A-C D-14,tiller,cults,Millcreek 25G spreader,
re: the UNIX 2038 problem...
from WIKI....
Alternative proposals have been made (some of which are already in use), such as storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer, providing a minimum range of 300,000 years at microsecond resolution.[18][19] In particular, Java's use of 64-bit long integers everywhere to represent time as "milliseconds since 1 January 1970" will work correctly for the next 292 million years.
Anyone REALLY care about 300,000 years broken down into MICROSECONDS ??
from WIKI....
Alternative proposals have been made (some of which are already in use), such as storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer, providing a minimum range of 300,000 years at microsecond resolution.[18][19] In particular, Java's use of 64-bit long integers everywhere to represent time as "milliseconds since 1 January 1970" will work correctly for the next 292 million years.
Anyone REALLY care about 300,000 years broken down into MICROSECONDS ??
I'm sure some geek or engineer somewhere does.
Sounds similar to the IPv6 solution to running out of internet addresses.
IPv6 gives us 340,282,366,920,938,463,463,374,607,431,768,211,456, that is approximately 340 undecillion, or 340 billion billion billion billion, addresses.
Now, if they could just focus on eliminating spam.
That is why the Mayans stopped the calendar at 5000 years. Not because the world was going to end. They just figured, yeah, 5000 years should be good for now.