ultra date validation?

[sera]

I have a customer that I think wants the moon on date validation. I'm asking you guys if I am unreasonable in saying that all these assumptions will result in data anomolies.

here are his requirements:
These are the forms he wants accepted and translated into mm/dd/yyyy:

mm/dd/yyyy
mm/dd/yy
yyyy/mm/dd
yy/mm/dd
m/d/yyyy or m/d/yy
mm/d/yyyy or mm/d/yy
m/dd/yyyy or m/dd/yyyy

He also asked to replace - : ; . with /

He also asked to accept dates without delimeters in all of the above formats.
ex. 01022005
ex. 122005
ex. 1205

He also asked to translate o,O to 0 and l,L to 1

He also asked to transform dates in Julian format then validate that
that date is possible

All the above is done without the user expressing their desired format.





Sera

 

[kaht]

I'm asking you guys if I am unreasonable in saying that all these assumptions will result in data anomolies.

If it's what your customer wants then I guess the answer is yes. When all these data checks have taken place and you have finally calculated the date that you assume the user is trying to input, just pop up a confirmation box that tells them what date your function has interpreted. At the bottom of this confirmation box just put a small message that is something along the lines of:

"If this is not the date you intended to enter then use the following format to enter your date: mm/dd/yyyy
Ex. 01/21/1995"

That should answer the question you posted. Hopefully you weren't expecting us to code the function for you. If you find it unreasonable for yourself surely you don't expect someone else to do the work (and not get paid for it I might add)

-kaht

...looks like you don't have a job, so why don't you get out there and feed Tina.

 

[sera]

I have most of this code written... I'm not asking for code.
I'm not even asking for a method to accomplish this. I'm asking if this request is reasonable and will maintain data integrity.

I see many examples that can fall under multi formats. ex. anything thats month date and year are <= 12 you can't determine what format it is. ex. 09/12/06 is that mm/dd/yy or yy/mm/dd or yy/dd/mm. Especially when you leave out the delimiters ie. 11105 is that 1/11/05 or 11/1/05. There are lots more.

My personal feeling is that for the best data integrity to force the user to input it in mm/dd/yyyy format. Then validate that that date can exist. That seems to be the way everyone does it. Its bacause if you allow all these possible formats you can't progromaticaly determine what format they have in their head.

Does anyone else agree?

Sera

 

[kaht]

Its bacause if you allow all these possible formats you can't progromaticaly determine what format they have in their head.

Hence the reason I suggested a confirmation box, and a "suggestion" of what date format to use if they can't get the date inputted the way they're thinking it should be.

There are lots of overlapping possibilities, and when you run into those possibilities always keep the same default across each one. In the case of possible overlap, always do mm/dd/yy for example. When you prompt them for confirmation and that's not the year they wanted then tell them how they should input the date.

-kaht

...looks like you don't have a job, so why don't you get out there and feed Tina.

 

[sera]

One of the requirements i didnt state before is there can't be input from the user, except that it is invalid.

Sera

 

[sera]

Sorry I failed to say in the original post that the customer is not allowing me to ask the user for ANY kind of format! I would be ok with the problem if I had that ability!

Sera

Sera

 

[sera]

Actually I did say it!

From the first post:
All the above is done without the user expressing their desired format.








Sera

 

[Acidcrawl]

I believe this to be an unreasonable request because it would be impossible to match the data to any one format without asking the user for SOME information. For instance say a user entered 030303, and it was supposed to me mmddyy, well this would also match ddmmyy or yymmdd. It's simply impossible to be accurate without input from the user.

 

[kaht]

For instance say a user entered 030303, and it was supposed to me mmddyy, well this would also match ddmmyy or yymmdd.

And it would be March 3, 2003 (or 1903) in all 3 cases.

I'll state it one last time and I suggest you take it to your employer to point it out to them, and if they don't like it then that's their fault.

When the date has been inputted, run your algorithm and display to the screen what it has interpreted in a format that they can not mistake:

"You have entered the date of January 01, 2005 for submission"

Make them confirm that this is indeed the date that they want. In the event that the date is not interpreted the way they expect (in other words, they click cancel) then show them a message similar to this:

"If the date you entered is not displaying the date you expected, try using the following format instead: mm/dd/yyyy"

Using this method you can still achieve that "All the above is done without the user expressing their desired format" unless they hit the cancel button.

Present your employer with the loopholes in the logic, present your solution, and then wait to see what they say about it. If they don't want a confirm box, and they don't want you to display a "desired format", then give them exactly what they're asking for. Calculate the date the way you interpret it and submit the information. Will some ppl input dates that they didn't mean to? Probably. But at least you tried your best to prevent that from happening.

-kaht

...looks like you don't have a job, so why don't you get out there and feed Tina.

 

[tsdragon]

Your customer is an idiot! Have you asked him what date you are supposed to assume the user intended if they do enter 11105? Since that could fall under several of your date formats, which one do you assume the user meant? You're quite correct in assuming that the request is unreasonable - it is! I simply cannot fathom the logic behind your client's stupid "requirements"! Anyone who would enter an l or an O instead of a 1 or a 0, or who cannot enter a date in a standard format should not be entering data in the first place. Is your client expecting to have trained chickens pecking out the data on the keyboard???

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[BillyRayPreachersSon]

I'm asking if this request is reasonable and will maintain data integrity.

It is NOT reasonable, and, if anything, will cause confusion rather than help integrity.

Your customer clearly needs putting straight.

Dan


[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[sera]

Haha, I am very appreciative of your responses and find them entertaining. Well the customer finally gave in. That was probably one of the most frustrating tasks I have ever been given. I was finally allowed to prompt the user when the date was entered incorrectly. Thanks for the commisseration. I really needed someone on my side

*This is one of those situations where the customer is not always correct!

Sera