The code worked differently when the moon was full
hanselman.com
The code worked differently when the moon was full
1–10 of 175 posts
Re: The code worked differently when the moon was full
#2> Not strictly the cycle of the moon but close.
Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds.
I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
Re: The code worked differently when the moon was full
#3Now, this is a true phase-of-the-moon bug: http://ftp.informatik.rwth-aachen.de/jargon300/phaseofthemoo...
Re: The code worked differently when the moon was full
#4> Bugs based on a time calculations can often show themselves later when view through a longer lens and scope of time...sometimes WAY longer than you'd expect.
When I worked for BBN in '97-'98, someone from outside the company as I recall came to talk to a room of engineers about the wide variety of calendar-related behaviors in various UNIX systems that were expected to cause problems for Y2K.
It was a very, very long list, often subtle issues, and I recall the concern in the room about the number of old systems in use by the DoD and others.
Anyway, no real point to this other than date handling is one of the hardest things to get right in computing, ranking right behind testing for the correct behavior.
Re: The code worked differently when the moon was full
#5Funny enough, Nethack[1] had this implemented too (w:spoilers). See also wmoonclock[2](wmaker) for a nice "moon-clock".
Re: The code worked differently when the moon was full
#6> Not strictly the cycle of the moon but close. Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds. I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
I was also hoping the title was more accurate. In the lines of the famous story of not being able to send an email 500 miles.
Re: The code worked differently when the moon was full
#7> Not strictly the cycle of the moon but close. Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds. I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
I was also hoping the title was more accurate. In the lines of the famous story of not being able to send an email 500 miles. https://web.mit.edu/jemorris/humor/500-miles
I always thought the problem was obvious by the title. And felt good about myself for a long time after I read it. Now that I am well into adulthood knowing does not seem that amazing.
Re: The code worked differently when the moon was full
#8> Not strictly the cycle of the moon but close. Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds. I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
I was also hoping the title was more accurate. In the lines of the famous story of not being able to send an email 500 miles. https://web.mit.edu/jemorris/humor/500-miles
Thanks for sharing, this is a great read!
Re: The code worked differently when the moon was full
#9> Not strictly the cycle of the moon but close. Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds. I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
I was also hoping the title was more accurate. In the lines of the famous story of not being able to send an email 500 miles. https://web.mit.edu/jemorris/humor/500-miles
The end of that article is a good reminder of the units command, I've been using Google for units conversion for so long that I forgot about the standalone units. It even comes standard with OSX.
Re: The code worked differently when the moon was full
#10Tangentially related, here's another fun bug that inexplicably cares what time it is: Open Office cannot print on Tuesdays (https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...)