And lest you think that's not a problem, consider that in 9999 we'll all be emulating hardware from 9950 emulating hardware from 9930 emulating hardware from 9900 . . . all the way down probably to emulating that C64. And it will *still* run faster than the C64. On Sun, Jan 4, 2009 at 7:46 PM, Robert Baillie <rjbaillie@frii.com> wrote:
with the earth slowing down due to tidal forces, i don't see that happening anytime soon.
if you want something to worry about, y10k is a much more urgent problem. when the year goes from 4 digits to 5, i hate to think of how many buffers will overflow!
bob ---
Dan Asimov wrote:
As I see it, anytime days > 367 (if leap year) or days > 366 (if not), the program should SCREAM.
--Dan
<< [Reminds me of the "phase of the moon" bug ... http://www.ccil.org/jargon/jargon_31.html]
comp.risks had more info on the Zune calendar freeze bug:
The issue is an infinite loop:
while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } } else { days -= 365; year += 1; } }
Under normal circumstances, this works just fine. The function keeps subtracting either 365 or 366 until it gets down to less than a year's worth of days, which it then turns into the month and day of month. Thing is, in the case of the last day of a leap year, it keeps going until it hits 366. Thanks to the if (days > 366), it stops subtracting anything if the loop happens to be on a leap year. But 366 is too large to break out of the main loop, meaning that the Zune keeps looping forever and doesn't do anything else.
_____________________________________________________________________ "It don't mean a thing if it ain't got that certain je ne sais quoi." --Peter Schickele
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
-- Check out Golly at http://golly.sf.net/