| « Database Changes Done Right | The Cheapest Fare » |
So it’s once again February 29... that one time every four years when newspapers do their fluff pieces about people who only have a birthday every four years, and you find all kinds of obscure bugs in your code. I managed to save two examples from the last leap day that I thought would be best shared today.
The first is from Eric, who wrote "my client is an alcohol company, and I run their website. They have a members-only section of their site that requires that you to enter your birthdate. If you're less than 21 years old, they kick you out and won't let you onto the site until you come back on and lie about your date-of-birth."
int intDay = (DateTime.Now.Day);
int intMon = (DateTime.Now.Month);
int intYear = (DateTime.Now.Year - 21);
string LegalYear = (intMon + "/" + intDay + "/" + intYear);
//validate birthdate first
if(!(Convert.ToDateTime(this.birthdate.Text) <= Convert.ToDateTime(LegalYear)))
{
this.messageLabel.Text = "Sorry, go away";
return;
}
"Yes. Rather than just doing a DateTime.Today.AddYears(-21), instead the original author decided to build a new string by concatenating the month, day, and year-21 of this date. Which means that today, 2/29/2008, it tried to parse into a DateTime the string '2/29/1987', which throws an (uncaught, naturally) exception."
Next up, Daniel shares this story from the last Feburary 29:
"I'm in support for a financial software company, but I work closely with the developers here. We kept having the same issue come up this morning from several of our customers. After puzzling over it for a while, we get a note in our e-mail from development:
"Two clients have called in already with "type mismatch error" before it ever even shows them the parameter screen. This is going to happen on any client that does NOT use calendar years as fiscal years that runs Widget Report. Workaround: run the report tomorrow or set system date to tomorrow."
"Seems as the software forgot to see that there was a February 29th this year, because when the fiscal years cross calendar years, it creates the months in the fiscal year based on the current calendar year. Since the year was created in 2007, there was no February 29th to be had. Let's just hope that there's no Feb 29, 2009 that comes up.
...and off-by-one errors. |
|
Hilarious note: after reading this, I over hear the head of the department who runs our client's alcohol site had the exact same issue today. Wonder how many others are out there...
|
|
I looked at the date on my (digital) wristwatch this morning, and noticed it said it was the 1st of March. Pressing the Adjust button, I discovered that setting back the date by one day put it on 29 February — which, of course, it had skipped past at 00:00 this morning.
Now, on the couple of previous digital wristwatches by this same manufacturer I've owned, you could set the year and the watch handled leap years automatically and correctly. (Those watches had the problem that their date couldn't go past 2000 and 2020, IIRC.) I can't really work out what the designers were thinking here … let's save memory by not storing the year, but then let's add a check to see if the user is turning the date back from 1 March so it can go to 29 February … WTF? |
| « Database Changes Done Right | The Cheapest Fare » |