[AccessD] Entering an ISO date with input mask and full validation

[James Button]

Susan,
Pretty much agree with the sentiment below.

My problems arise when the data is not adequately validated or, in the case of numeric entry of dates, where the software does not easily allow differentiation of the users intention - especially when the users entering the data are from a wide range of ethnic backgrounds, and in many cases not experienced in IT assumptions.
However (probably from using interactive phones) it is increasingly becoming the case that even infants recognise date entry forms of _ _ _ _ /  _ _ / _ _ are to be entered as yyyy/mm/dd 

And .. while Access  does have some constraints, and data entry by 'users'  is usually limited to through forms, Excel is a real pain as the current versions no longer allow validation of data entered directly into a cell to have the input characters checked - you just get to see what Excel decided to generate as it interpreted the users input.
01/02/03  being Jan 2nd 2003, Feb 1st 2003 or maybe the 3rd Feb 2001, or maybe .. depending on the OS and app settings and current date maybe 1903 or 2103.

My consideration - in Excel - is that the pain is caused by the interpretation Excel does, because once excel has the data - you're stuck with what it calculated as the - 1900 or 1904 based - number associated with that date.

JimB 

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Monday, January 18, 2016 7:44 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Entering an ISO date with input mask and full validation

I acknowledge that we all have different ways of expressing dates (verbally and written). I have never had the talent for understanding or speaking a foreign language. I can't even understand other Americans with accents! :) 

I have no problem entering, modifying, manipulating, grouping, or sorting dates entered in the US format Jan 1, 2016. I would imagine that cultures entering them differently can say the same thing. The software handles our needs. 

It's only when we have to work with dates not in our familiar zone that we run into trouble. If I were working in an organization that had to face this problem, I would hope to find a solution that was efficient and accurate, but I'm not sure I would spend much effort into trying to force those submitting dates in a "foreign" format into my culturally biased format unless of course, I had the power and money behind me to make it happen. :) I hope that makes sense and doesn't offend anyone. It's just an opinion and how, I think, I would deal with this if I had to. It's probably how most of you handle it -- you make it work. 

I often get questions from readers with similar dirty data issues and they want solutions for fixing the data. My first question is always the same -- can you take it back to the source and get them to submit it the way you need it in the first place? But you know, all too often, that isn't possible. 

So, I don't understand why this is always such a heated discussion or why any camp claims superiority. Dates are no different than any other data we have to accept and fix before we can use it. 

I say that all gently and with no judgement, just ... the way I see it. 

Susan H. 

Hi Susan and David

And so is the logic. You would say ”224 Grand Aveny” while we always will say ”Big Street 224”.

/gustav



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com