9/9/99, 01/01/00, and. . . 4/9/99?

I just read today in a company publication that mentioned that we had had no problems with Y2K, and that we had not had had any problems with other dates that had been identified as potential problems, such as 4/9/99 and 9/9/99.

I heard about 9/9/99, and I knew that it was a load of hockey when it was first brought up, but what was the deal with 4/9/99?

This was the first I had heard of it.

Actually 9/9/99 was a concern, but not with Hardware or OS’s but other applications that used the 9999 monicer for a place holder for an automated instruction rather than a date.


She caught your eye like one of those pointy hook latches that used to dangle from screen doors and would fly up whenever you banged the door open again.

I think 4/9/99 is (was supposed to be) a problem because it is day number 99 of 1999.

The scaremongers are also dragging out 2/29/2999 – the “unexpected” leap day for the year 2000.

It seems to me this one is really stretching it – a program would have to know to drop out leap days for the divisible by 400 and not know to leave them in for divisible by 1000. Seems to me if they got that far they’d get it right.

There is no opinion so absurd that some philosopher will not express it.
Cicero

Along these lines, I recall reading a while back that there was supposed to be some date in August of last year, on which global positioning systems (probably the wrong name) were supposed to fail. I forget when, I forget why. Does this sound familiar to anyone or are the pain meds getting to me?

But remember, we’re not out of the Y2K woods until we get to March 1, 2100 :o. When some computers think it’s February 29th, 2100 a day that doesn’t exist civilization will fall. Mark my words! I’m already starting to stockpile food… :smiley:


It is too clear, and so it is hard to see.

Gilligan

This is weird. I work for a utility company, and last year on September 8, a local news guy reported that our company had done all the necessary testing, and had only had one problem, and that that problem had been remedied.

That got me curious, and I started asking around (since I work in the IS area, and had not heard about it).

Nobody had an answer. Nobody. No one on our Y2K project team had known about it, either.

Finally, someone said that they had heard that when they rolled the dates forward to 9/9/99, there was concern about our GPS stuff.

Again, no proof that anything had actually happened, but that appears to have been the source of the reported problem.

I just assumed that whatever component had had a problem was probably due to an incidental license expiration that happened before 9/9/99. That is, when the tests were done in August, that some component’s license agreement was due to expire before 9/9/99.

In short, I heard the same sort of thing, but I don’t have any details.

9/9/99 was not a problem because a computer would need to store the date as 090999. Two digits each are needed for the day and month.

Actually george, it all depends on who wrote the app. On most commercial software you are correct, however in house programs may not have required a 2 digit month or day.


She caught your eye like one of those pointy hook latches that used to dangle from screen doors and would fly up whenever you banged the door open again.

I had a little time to do a quick search on that, Mjollnir. Here is one link that might explain it.
http://www.doi.gov/oirm/y2k/gps.html

download.com has a hardware tester that runs about 270 y2k tests,:
A total of
267 individual checks are performed in seven test groups. The test groups
include year and century rollover, leap year logic, Y2K date retention, century
rollover after reboot/power-off, leap year logic after reboot/power-off, Y2K date
retention after reboot/power-off, and hardware type.

Holy hell, ya mean we have to deal with all this shit for another century?


“Wednesday the 15th - Chris made one of her rare good points today.”
Guanolad