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.
Gold/Mining/Energy : Gold Price Monitor
GDXJ 121.93+0.8%Jan 9 4:00 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Alex who wrote (20000)9/29/1998 2:38:00 AM
From: Investor-ex!  Read Replies (1) of 116845
 
[off topic]

Alex,

IMO, the 9/9/99 story is mostly hype -- technical gibberish at its best. It makes for a good story, but current practice doesn't support the claims made.

The date, September 9, 1999, wouldn't ordinarily be stored as 9999, even on non-Y2k-compliant databases. Note that to properly store the month, two digits are required. Ditto for the day of the month. In those databases that do not have a native date data type, most non-compliant dates are stored in YYMMDD fashion, instead of in the Y2k-ready CCYYMMDD format. For the most part, September 9, 1999 would appear in non-compliant databases as 990909, not 9999.

This is because one of the main requirements of data storage is the ability to perform sorting of an entire file based upon the value of a given field. Dates, especially, are used in this fashion. Storing a date as YYMMDD serves this requirement quite well up to, but not beyond, 2000, where all post-2000 dates would then sort to the beginning of the file instead of at the end where they belong.

However, a storage scheme where leading zeros in the month and day-of-month subfields of a date are deleted (9999) would be useless in this regard. The size of the field would expand and contract depending on what month or day-of-the-month it was, rendering it impossible to build any kind of rational index over the field.

I suppose it's not beyond the realm of possibilities that there are databases storing dates this way, but, as explained above, these date fields would already be of limited practical use, even now, and would impact processing marginally, at best. So, I would expect this particular problem to be negligible.

This is not something I would bet money on. I'd actually be quite surprised if there are any noticeable effects on September 9, 1999. In fact, if people are expecting problems from 9999 and none materialize, and stocks rebound because this is cited as "proof" that Y2k is a hoax, I'd wait for the rally to run its course and then short aggressively afterwards.

9/9/99 is a side-show, Y2k is not.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext