Validate a field content if it is a date

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

SparkOut
Posts: 2839
Joined: Sun Sep 23, 2007 4:58 pm

Re: Validate a field content if it is a date

Post by SparkOut » Thu Feb 25, 2010 2:47 pm

Aye, I do similar Klaus, danke - although it doesn't suit every situation and requires extra processing. It seems astonishing that something like that should still be an issue to deal with natively in Rev, and that hardly anybody seems to think it's of any importance.

Adrien
Posts: 26
Joined: Fri Jan 09, 2015 9:55 am

Re: Validate a field content if it is a date

Post by Adrien » Sun Nov 15, 2015 4:25 am

Old topic but might help,

To check if a string with the mm/dd/yy or mm/dd/yyyy format is a valid date, you can use:

Code: Select all

put "mm/dd/yy" into theDateToCheck
convert theDateToCheck to seconds
if theDateToCheck is an integer then -- has been translated into seconds
answer "it is a date"
else -- theDateToCheck has not changed
answer "it is not a valid date"
end if
because it will fail to convert the 30th February (for instance) to seconds!

aetaylorBUSBnWt
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 118
Joined: Thu Sep 20, 2012 5:11 pm

Re: Validate a field content if it is a date

Post by aetaylorBUSBnWt » Fri Sep 30, 2022 4:31 pm

Joerg wrote:
Thu Feb 18, 2010 8:57 pm
Hi,

I have a field, say txtDate, where I would like to validate whether the user has entered a valid date or not:

Code: Select all

set the useSystemDate to true
if fld txtDate is a date then put "true"
else put "false"
When I put a any number into the field then, say 1 or 123 or whatever, the validation results in "true" although it is not a valid date value. What am I doing wrong?
Well, it is long after the question was asked, but I had it, so maybe it is a useful answer.
My solution restricts the user input and ignores countries. If "current country" is a thing and can be found, modify accordingly.
My attitude is KISS.
So MM/DD/yyYY for the date format, where only two characters for year are required.
function checkDate pDate
local tNumb;
set the itemDelimiter to "/"
put item 1 of pDate into tNumb;
if tNumb is a number and tNumb > 0 and tNumb < 13 then
put item 2 of pDate into tNumb;
if tNumb is a number and tNumb > 0 and tNumb < 32 then
put item 3 of pDate into tNumb;
if tNumb is a number and tNumb > 21 then
put item 4 of pDate into tNumb;
if tNumb is not empty then
return false;
else
return true;
end if
end if
end if
end if
return false;
end checkDate

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9580
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Validate a field content if it is a date

Post by dunbarx » Fri Sep 30, 2022 4:41 pm

I think it far better to deal with date validation.

The OP states, correctly, that, say "-42" is a date. This certainly could, on the face of it, cause problems. Any floating point number is interpreted by LC as a valid date

But I would filter that sort of thing out. Per the previous post:

Code: Select all

if fld txtDate is a date and txtDate is not a number then put "true"
There may be other possible values of "txtDate" where additional filtering is required.

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Validate a field content if it is a date

Post by FourthWorld » Fri Sep 30, 2022 5:53 pm

In HTML, FileMaker, and most other tools where making forms is a common task, input filtering by type is a property setting, no code required.

Consider the range of options provided in HTML for not only date but also time, email, URL, and other common types:
https://www.sitepoint.com/html-forms-co ... ete-guide/

The world has changed over the last 30 years. A lot. In 2022 devs don't usually expect to hand-craft code for things as common as input validation.

Adopting the validation model and scope of HTML form inputs would go a long way toward freshening LC for today's expectations.

As for "is a date" returning true for numbers, most computers would agree, and most end-users would not.

Rather than require new users to learn the underlying computer science that explains why "123" is viewed by a computer as a date and then come here to look for ways to filter input to match end-user expectations, it would seem useful for the language to include a new evaluator that fits those expectations out of the box.

I wouldn't suggest "humanExpectedDate" as such an alternative to "date", but something providing that sort of functionality would seem useful.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9580
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Validate a field content if it is a date

Post by dunbarx » Fri Sep 30, 2022 7:15 pm

Richard.

Mainly agree, except that it takes one line of code to put to rest the floating point issue.

The question then is are there more "things" to worry about? Are some "things" universally not "expected" to be dates?

It is best, I think, to have control over the validation. It may well be that something similar to "-42" is what the dev wants explicitly to recognize as a date, for whatever reason. In other words, the "humanExpectedDate" function may only work when the dev knows his audience perfectly.

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Validate a field content if it is a date

Post by FourthWorld » Fri Sep 30, 2022 7:30 pm

dunbarx wrote:
Fri Sep 30, 2022 7:15 pm
... the "humanExpectedDate" function may only work when the dev knows his audience perfectly.
To be clear, I'm not proposing a humanExpectedDate replace date but merely be an option, for the majority use case where the end user expects dates in LiveCode apps to look like dates in every other app and the OS they're using.

The background behind the design patterns implemented in modern HTML is informative. The teams reviewed literally tens of thousands of web UIs, found the most common patterns, and made them easier for devs to implement.

None of that massive research effort and resulting enhancement stops anyone from scripting custom solutions where needed.

But it does save devs collectively millions of hours in not having to reinvent common wheels.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Post Reply

Return to “Talking LiveCode”