Re: Re: Date conversion with Class::DBI

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... :-)

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

Replies are listed 'Best First'.
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]