As part of my current job of porting an application to Google Gears I wrote a snippet of JavaScript to validate that a user enters a date in the format ddmmyyyy or ddmmyy. The users are using PDAs so we really don't want them to have to do it in the format dd/mm/yyyy. The less key taps needed the better.

Here's the code:

var re = /^(0[1-9]|[12][0-9]|3[01])(0[1-9]|1[012])((19|20|)\d\d)$/;

//Test format first
if (re.test(input)) {

 var bits = input.match(re); 
 if (bits[4]==""){
  bits[3]="20"+bits[3]; //Will last 91 years before breaking!
 }
 
 var entered = new Date(); 
 
 entered.setFullYear(bits[3], bits[2]-1, bits[1]);

 //Validate range here if needs be
                                                        
} else {
 alert("Not a valid date!");
}

The end result is a JavaScript Date object representing the date entered, which you can do with as you must.

When Hard Coding Is Ok

What keeps making me think about the code is the bit where I've hard coded the 21^st century in to any date where the century part isn't specified. In 91 years it will break. As an opponent of all things hard coding I can't decide how happy I am with it.

Although I know the application itself will, like me, be long dead by the year 2100 it's just bugging me. Is it ever ok to knowingly introduce a bug, even if you know the bug will never get to live?

A Simple Fix

In this case it would be trivial to remove the bug, so that it always added the current century when none was specified:

bits[3]= new Date().getFullYear().substr(0,2) + bits[3];

I just can't decide whether I should retrofit this fix or not. Maybe I should. Then, should a source of eternal life be found by then, I'll be guilt-free.