> a true date-of-Easter complication is probably the single most difficult complication in horology Funny story. I was making the "final" commit before shippi

> a true date-of-Easter complication is probably the single most difficult complication in horology Funny story. I was making the "final" commit before shipping a desktop application, and I wanted to make an Easter egg. But what should it be? It should be Easter-related, I supposed. I made a pastel color theme for the main screen, that should appear only on Easter. This product is used in DoD, and I doubted that anyone would ever be using it on a Sunday. The product had a design flaw, a kind of time bomb. I was a greenhorn working on it when it first shipped in 1994, and I thought nothing of the fact that its rate table was arranged horizontally, like so: id 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 1 4.49 4.59 4.79 4.99 5.16 5.26 5.68 5.78 5.99 6.44 2 ... etc Despite being a Navy budget forecaster by trade, the Captain who created the program lacked the hubris to worry about needing rates for the next millennium. This set of dates was hardcoded all over the the codebase. The Captain, a poor typist, kept resetting the bomb by adding more years. Fast forward to 2012. The product has been acquired, and I was brought in to port it for 64-bit machines. And the only task remaining—revision #1400—was to compute the date of Easter. It took me about 2 minutes to conclude that this wasn't going to happen (although I didn't know it was that hard). So although it lacks the elegance that you'd like in your Easter egg, this one hardcodes the dates of Easter Sunday... through 2020. I mean, it's going to be on the web by then, right? Yeah, it's still shipping. http://www.budgetbuilder.com/ http://www.budgetbuilder.com/