But at the end of the day, they can have whatever they want to pay for.

I suspect that you haven't thought this through. Presumably if you gave them certain things without exculpatory documentation that you warned them of the dangers and they still insisted that you could be sued after the fact for far more money than you have been originally paid.

Consider an engineering firm hired to build a bridge. The client then asks that some ornament was placed on the bridge that under certain circumstances (unusually high winds perhaps) could pose a threat to the structural integrtiy of the bridge or a threat to life and limb. If the firm involved knows these risks, and fails to communicate them to the client in such a way that the client takes all responsibility for the consequences then it certainly would be in the position to be sued for every penny it had for negligence, or perhaps even worse.

To be honest it may be in the case of construction that _whatever_ happened the engineering firm would be at fault. And as such the onus is on them to refuse to perform such a service. I dont know. The point is still valid IMO.

And what does allowing two digit years (you mentioned you wanted to allow this), and odd date formats imply? Well its a threat to the structural integrity of the data. And I suspect that if you allowed that to happen you could be sued for allowing the DB to be corrupted.

So, while I can see how its difficult to tell your customer NO, its not difficult to write a document advising them of the risks of allowing such things and getting them to sign that they understand the implications before you do so. At the bare minimum it will protect your ass from potential law suits.

PS, the idea of prefilled fields or a button that puts in todays date or whatnot sounds like a good way to ease the pain of repetitive entry while at the same time ensuring the integrity of the data.

Anyway, theres the cynical other point of view for you. :-)

And what does allowing two digit years (you mentioned you wanted to allow this), and odd date formats imply? Well its a threat to the structural integrity of the data.

Actually, I was thinking more along the "be liberal in what you accept from others" vein. This doesn't have to conflict with data integrity.

Also, I can't bring myself to code defensively against law suits.

Accepting 2 digit years does conflict with data integrity. There are at least three commonly used interpretations of 01/02/03 (is it 2001-02-03 => YY/MM/DD or 2003-02-01 => DD/MM/YY or 2003-01-02 => MM/DD/YY ?) (And when you include uncommon formats it gets worse.) Being liberal in what you tolerate doesnt mean you have to tolerate totally ambiguous input.

Beside the lawsuits Id be thinking of all the hassle of cleaning up the data when you get an American in the office (or any nationality NOT the one you are designing for.)

Anyway, i'll let it rest now, and hope you realize I said all of this in the best of intentions. :-)

Regards,


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}