The problem was the months with 30 days April, June, September and November (4,6,9 and 11) failed every check. I couldn’t figure out way because the worked like a charm with the regulator and nothing in the regex was .Net specific.
I’d changed the expression on the regexlib but I still was not 100% sure of what the “bug” was. There seems to be a problem with the negative lookahead . At first I thought it didn’t allow special characters inside of it because none were acting like I thought they would or like they did in .Net. I starting to think it was a short-circuit issue where the JS engine is negating each character before evaluation it and stopping on the first non-match. Where I think the.Net is evaluating the entire group then negating the result.
Well a little further testing shows that this problem seems to be Mozilla based. A test string that failed in Mozilla and Firefox passed in Opera and IE. Looks as if the character classes are short-circuiting meaning if you have a negative lookahead that uses a character class say ^\d(?!\.\d5) which should match a digit that is not follow by a decimal then a digit then a five. 1.25 shouldn’t match but 3.14 should.
The Mozilla bug would cause 3.14 to fail because it would negate the \d making it not a digit (\D) and upon the ‘1’ not matching that criteria would end the check without looking at the rest of the lookahead to see if the next characters is or isn’t a 5. I’ve reported this bug to Mozilla , Bugzilla bug 254296,so it’s in their hands now. and it has been fixed.
Now while both problems had something to do with lookaheads you should still test with multiple browser if you are going to do any client-side validation with regexes to see if any other bug are scampering around.