Re: Date conversion with Class::DBI

I know im not going to be popular for saying this but I think you should take a different tack. Tell you users that they have to use YYYY-MM-DD and be done with it. Even though I can hear the "boo hiss" I have a strong point here. The fact is that ISO dates are there for a reason. They are standard in Europe, they are specified in Duden in Germany (not to mention being a DIN standard as well), the US military uses them etc. Frankly its not unreasable to say that anybody sane uses ISO dates. Sure you may hear a bit of grumbling but after a week or two they wont even remember being able to enter dates in such a foolish format as DD/MM/YYYY. And actually I bet a whole bunch of them are quite used to using ISO formatted dates and wont even bat an eye.

What I would do is ignore the issue. Then if they asked I would say no. Then when they pleaded I would tell them to get a budget to write the code to handle the format and tell them itll be at minimum two weeks to sort out. Then they will go away. :-)

And before anybody rejoins with one of those "following orders" kinda reply, ask yourself this: if the user asks you to design the system so that some kind of horrible bug is possible, say one that would allow under some circumstance the DB to be wiped or the filesystem to be corrupted or something, just so they can have some "feature" of dubious worth would you do it? I know I wouldnt. My company hires me because Im (more or less :-) a professional. They hire me to give professional opinions, and to Do the Right Thing. They hire me (and you) because we have skills and knowledge they need, not to blindly follow orders. So when I say to them "No, i wont do that, its a bad idea for these reasons" I expect them to listen. If they choose to overrule me then I ask for it on paper. It is _very_ rare that a user/manager etc will overrule you when you insist on paperwork to show they will carry the can if something goes wrong. The very fact that you insist shows them that you are pretty much certain they will end up with egg on their face. And nobody likes that.

NOTE: as my be able to tell :-) I have strong feelings on this particular subject. IMO no computer program should either emit or accept any human readble date format other than an ISO compliant one. (Well, except under extreme duress.)

---
demerphq

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

Comment on Re: Date conversion with Class::DBI Download Code

Replies are listed 'Best First'.
Re: Re: Date conversion with Class::DBI by runrig (Abbot) on Jul 09, 2003 at 23:35 UTC
Tell you users that they have to use YYYY-MM-DD and be done with it. Computers are supposed to make things easier. If I told all my users (customers at client sites) they had to enter 'YYYY-MM-DD', most of them would throw fits, and rightfully so, IMHO. The only downside is that we use a 4gl (not perl) for the data entry, and it automatically converts different entered formats, but we don't have complete control over the conversion, and it allows, e.g., '050103' to mean '2003-05-01', which is fine by me, but if (and I mean when) that last '0' is accidentally left out, and they enter '05013', it is interpreted as '0003-05-01'. If they enter '5/1/3' it is interpreted correctly, but they'd rather just use the numbers on the number pad. And don't ask whether it would be easier for them to enter YYYY-MM-DD rather than have me fix the data when it goes bad... :-)	[reply]
Re: Re: Re: Date conversion with Class::DBI by demerphq (Chancellor) on Jul 10, 2003 at 07:50 UTC
Computers are supposed to make things easier. Computers are supposed to make the possible easier. But they can't do much with the totally ambiguous. And I suspect that they wouldnt throw fits as often as you think. Especially if they were shown the obvious benefits of reduced maintenance (that they pay for) that can be obtained by not using ambiguous formats. Also IMO most corporate types like the idea of being ISO compliant. --- demerphq _{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}	[reply] [d/l]
Re: Re: Re: Re: Date conversion with Class::DBI by runrig (Abbot) on Jul 10, 2003 at 17:41 UTC
But they can't do much with the totally ambiguous. I don't see how its ambiguous if its defined and documented behavior. If a certain environment variable is set to 'MMDDYY' then you've got Ameri-centric dates, if its 'DDMMYY' then its more like the rest of the world. But like I said before, when we define a date field in our 4GL forms, we have no control (other than that environment variable) over what format is allowed or not, but at least its documented. One funny thing is that when I was writing something to access the database through ODBC, selecting a date field returned dates in 'YYYY-MM-DD' format, but if you turned around and tried to use that in a where clause, you'd get a syntax error (it's an old version of an Informix database, I don't know if newer versions accept 'YYYY-MM-DD' format).	[reply]
Re: Re: Date conversion with Class::DBI by bsb (Priest) on Jul 08, 2003 at 00:13 UTC
Refreshing. But the people using this repeatedly deserve a short form. Or at least a shortcut. Maybe prefilling the field with 2003-00-00... Javascript help... But at the end of the day, they can have whatever they want to pay for. Brad	[reply]
Re: Re: Re: Date conversion with Class::DBI by demerphq (Chancellor) on Jul 08, 2003 at 06:35 UTC
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. :-) --- demerphq _{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}	[reply] [d/l]
Re: Re: Re: Re: Date conversion with Class::DBI by bsb (Priest) on Jul 08, 2003 at 08:48 UTC
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.	[reply]
Re: Re: Re: Re: Re: Date conversion with Class::DBI by demerphq (Chancellor) on Jul 08, 2003 at 10:38 UTC