Maybe if you put something like what I just said in your FAQ, or somewhere else that someone must read before they post.

WE WILL NOT ACCEPT REGEX FOR THE FOLLOWING:

- email validation (see RFC 2822/822 for why this is hard)
- date validation (especially if you don't consider M/D/Y vs D/M/Y)
- HTML parsing of ANY kind

And then just keep updating the list as other "hard" problems.

And actively *delete* anything in these "hard" categories. Don't make me downrate them, just to have some other clueless fool come along and upvote it because it "works" for them.

*That* would greatly increase the quality of your pattern database. Really.

If you give me rights to delete (make it a big button that just makes the regex go away and email the original submitter with the FAQ), I'll be happy to help you police the site.

I'm not a guy who just complains without being willing to help. Here's my offer to help.

While I agree that regular expression are not appropriate for solving every validation problem I'm not onboard with the don't ever using a regex for this type of problem attitude. I think there are other factors that influence if a regex approach is a good or bad thing. I have written regexes of each type mentioned above and their usefullness or lack of is not always as staightfoward as people seem to want them be. I agree that email validation with a regex is not a good idea in general because it is impossible to write a regex that is 100% compliant with RFC 2822 but if you are only working with a subset of mailboxes it may be a viable option. And as bad email validation with regexes it is a better candidate than phone numbers. As difficult as the regex maybe at least email is an international standard. Phone number formats vary from country to country. Yet phone numbers is probably one of the most common example of uses for regex.
I've written many date regexes. How useful or not they are is something for the people actually using them to decide. However I have personally learned more about regexes in writing them than i could have ever learned from writting "simple" regexes. This includes how certain feature actually work as well as various bugs in an implementation of regular expressions. I've also learned about the good and bad of some non-regex date validators which might be consider better alternatives. Several people have written stuff based off my work, hopefully they've learned something other than how to cut and paste.
But I have to say i disagree with HTML parsing the most. I think this is really a problem specific case and this is true of other type of markup. A lot of common things people want to do with HTML shouldn't be done with a regex, such as document navigation but HTML editors with regex find and replace support can be a godsend.

I think the rating system on the regexlib does fall a little short because there is too little thought put into some of the positive ratings and too little evaluation and feedback put in some of the negative. To me negative rating with no example and/or feedback is pointless.
I do the a FAQ is a good thing but I don't think banning certain problem sets is a good idea. You may learn more from writting "hard" regexes that you almost never use than the simple ones you use daily. Maybe give a strong warning of the common pitfalls of those problem sets and some general alternatives. I often see people suggest a .Net alternative to regex problems but that only helps if you are working with .Net. If you are not then the regex option starts look better again. If you have a code alternative and don't know what language the person is using just offer a psuedo code solution.

While I agree that regular expression are not appropriate for solving every validation problem I'm not onboard with the don't ever using a regex for this type of problem attitude. I think there are other factors that influence if a regex approach is a good or bad thing. I have written regexes of each type mentioned above and their usefullness or lack of is not always as staightfoward as people seem to want them be. I agree that email validation with a regex is not a good idea in general because it is impossible to write a regex that is 100% compliant with RFC 2822 but if you are only working with a subset of mailboxes it may be a viable option. And as bad email validation with regexes it is a better candidate than phone numbers. As difficult as the regex maybe at least email is an international standard. Phone number formats vary from country to country. Yet phone numbers is probably one of the most common example of uses for regex.
I've written many date regexes. How useful or not they are is something for the people actually using them to decide. However I have personally learned more about regexes in writing them than i could have ever learned from writting "simple" regexes. This includes how certain feature actually work as well as various bugs in an implementation of regular expressions. I've also learned about the good and bad of some non-regex date validators which might be consider better alternatives. Several people have written stuff based off my work, hopefully they've learned something other than how to cut and paste.
But I have to say i disagree with HTML parsing the most. I think this is really a problem specific case and this is true of other type of markup. A lot of common things people want to do with HTML shouldn't be done with a regex, such as document navigation but HTML editors with regex find and replace support can be a godsend.

I think the rating system on the regexlib does fall a little short because there is too little thought put into some of the positive ratings and too little evaluation and feedback put in some of the negative. To me negative rating with no example and/or feedback is pointless.
I do the a FAQ is a good thing but I don't think banning certain problem sets is a good idea. You may learn more from writting "hard" regexes that you almost never use than the simple ones you use daily. Maybe give a strong warning of the common pitfalls of those problem sets and some general alternatives. I often see people suggest a .Net alternative to regex problems but that only helps if you are working with .Net. If you are not then the regex option starts look better again. If you have a code alternative and don't know what language the person is using just offer a psuedo code solution.

I wrote a big, long comment, but decided it was too long so I just blogged it instead:
http://regexadvice.com/blogs/ssmith/archive/2005/04/01/3258.aspx

Well, I'm tired of web forms invalidly rejecting my very valid email of "fred&barney@stonehenge.com". There's no f'ing reason to reject that. It's valid RFC822. If you're gonna play on the net, play nicely.

I've made comments in the other blogs in this thread as well.

Some problems do not require bullet proof solutions. A regex for parsing internet addresses may be a little bit naughty, but it can be implemented quickly and cheaply. I can imagine dozens of uses for such a regex. In many applications only a small range of dates would be accepted. Of course the date regex might not be accurate in a universal sense, but that does not mean it could never have application.

As Michael Ashe mentioned, validating telephone numbers is even more difficult than email because each nation adopts its own "standard". Yet, many business applications would need to parse only numbers included in the North American Numbering Plan. Or in metropolitan Chicago.

Rather than deleting all date/html/email/Phone number regexes, perhaps it would be more useful to document the shortcomings of these patterns and explain why they should only be used where appropriate.

Randal Scwartz is justifiably annoyed that web forms reject his email address, but that is not really a regex problem but a business logic problem, i.e. instead of rejecting the suspect email address the site could send a confirmation request to it. BTW, just how would a person "properly" validate an email address?

Perhaps it would make sense to create a catagory of hard or not universally applicable regexes with specific catagories for email, phone, email and dates. If the heading of each gives a brief explanation of the caveats to their use and links to a page with more detailed explanations, then those who might have use for these patterns will have them. Caveat Emptor.

I agree with Alan Lindsay, even the existing date regexp have utility. Maybe they just need better organization &/or categorization.