Since we're making a few predictions this morning, allow me to give myself a long leash to hang myself on with the following:

I predict that Feb 29 will be a non issue (Jan 31 is another matter as I have explained on 1.1.2000 in LINK)

Here's why:

The bozo programmers who don't know the leap year rules will be saved by fluke since 2000 is divisible by 4 and is a leap year.

The smart programmers who know the leap year rules will say, "So what". I don't need to program them until 2100, because until then the divide by 4 rule is good enough and I know that all my software won't be in use by 2100 (hmm, seems to me I've heard that before, ah yes it was said in reference to software that won't be in use in 2000 so it would be ok to use 2 digit year programming).

The only time there will be problems on Feb 29 if there were some real smart ass programmers who know the rules and programmed them incorrectly or there were real bozo programmers who know about leap years but couldn't even program the divide by 4 rule properly (or even better forgot leap years exist - in which case their apps already blew up in 1996).

The chances of a someone knowing the century leap year rule, but not the 400 year rule are almost zero in my opinion, as the one rule is never mentioned without the other.

So the errors that occur on Feb 29 will be the result of sloppy programming, not due to igorance of the fact that 2000 is a leap year. These, my guess is, will be few and far between unlike y2k where deliberate decisions were made not to program 4 digit years and therefore the problem was a design issue rather than just sloppy programming.

-- Interested Spectator (is@the_ring.side), January 07, 2000

Answers

I'm confused. 2100 is divisible by 4 as well. In fact, all century dates are divisible by 4. What is the issue here?

billy d

-- billy d (billyd@aol.com), January 07, 2000.

The rules for leap years are as follows:

Leap occurs if the year is divided by 4. Leap years do not occur on the century years, except if the century year is divisible by 400.

-- Interested Spectator (is@the_ring.sideq), January 07, 2000.

Agreed I.S. No programmer I know of would expect their code to still be running in 100 years. (But wasn't that the mindset that got us in this in the first place???) :-)

To other questions:

There is a leap year every 4 years, unless the year is evenly divisible by 100, then it's not a leap year, unless the year is evenly divisible by 400, then it IS a leap year anyway.

-- mark (anvilmark@yahoo.com), January 07, 2000.

The rule for leap years was changed. In the Julian Calendar a year is a leap year if it is divisible by 4. In the Gregorian Calendar a year is a leap year if either (i) it is divisible by 4 but not by 100 or (ii) it is divisible by 400. In other words, a year which is divisible by 4 is a leap year unless it is divisible by 100 but not by 400 (in which case it is not a leap year). Thus the years 1600 and 2000 are leap years, but 1700, 1800, 1900 and 2100 are not.

julian/gregorian calendar

-- Grant Naylor (web@srfin.net), January 07, 2000.

During the last leap day (Feb 29, 19996) one of the local colleges had a date failure in one of their door locks.

No, obviously not TEOTWAWKI nor do I think that this coming Feb 29 will be either (nor did I think Jan 1 was going to be).

But blanket statements as "total non issue" are going overboard the other way.

Mikey2k

-- Mikey2k (mikey2k@he.wont.eat.it), January 07, 2000.

There might be a leap year error or two out there. Probability seems pretty good. As for it causing enough trouble for us to hear about it, that seems much less likely. But it won't be correct to conclude that there were no such errors just because we didn't hear of any.

-- Flint (flintc@mindspring.com), January 07, 2000.

Ok, TOTAL was a bad way to express the concept. I should have said 99.99999% of all systems will have no problems.

Happy?

-- Interested Spectator (is@the_ring.side), January 08, 2000.