Skip to content
This repository has been archived by the owner on Feb 14, 2019. It is now read-only.

Set Date to null if character entered is non alpha numeric instead of 31 December 1899 #434

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

davidpatters0n
Copy link
Contributor

The purpose of this pull request is to address the potential affect of entering a non alpha-numeric which sets the date back to 31 December 1899 as shown
This change simply matches against any single non alpha-numeric character and returns null. Example shown

@davidpatters0n davidpatters0n force-pushed the bug/prevent-bad-characters branch from 8787091 to 15019f3 Compare September 30, 2015 19:13
@ahmetabdi
Copy link

👍

@davidpatters0n davidpatters0n force-pushed the bug/prevent-bad-characters branch from 2b5d425 to aa66c88 Compare September 30, 2015 23:13
@davidpatters0n davidpatters0n changed the title Set a new Date instance if characters are bad Set Date to null if character entered is non alpha numeric instead of 31 December 1899 Oct 1, 2015
@AuspeXeu
Copy link
Collaborator

@davidpatters0n Could you explain the regex to me briefly, please? Thanks!

@davidpatters0n davidpatters0n force-pushed the bug/prevent-bad-characters branch 2 times, most recently from 61a2491 to 8180c81 Compare February 4, 2016 15:21
@davidpatters0n
Copy link
Contributor Author

@AuspeXeu the regex will match characters that are numeric and followed by a hyphen followed by another number more than 1 or more times.

@AuspeXeu
Copy link
Collaborator

AuspeXeu commented Feb 4, 2016

@davidpatters0n So this is format specific as it requires the user to use hyphens. Is that correct?

@davidpatters0n
Copy link
Contributor Author

Correct. As shown in the above gif in the description you'll see that entering a hyphen in this instance will cause the date to be set 31 December 1899

@AuspeXeu
Copy link
Collaborator

AuspeXeu commented Feb 4, 2016

But wouldn't it make sense to have it tolerate different date formats? Maybe even rely on the format that is currently set for the component?

@davidpatters0n
Copy link
Contributor Author

That is correct. As shown below, i ran the regex against a series of different date formats and it seems to comply.

!(/^(\d+-?|\d+\/?|.)+\d.*/).test('2015-04-05')
false
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('05-04-2015')
false
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('05/04/2015')
false
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('2015/04/05')
false
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('-')
true
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('?')
true
!(/^(\d+-?|\d+\/?|.)+\d.*/).test('^')
true

@davidpatters0n
Copy link
Contributor Author

And I also think maybe it would be a good idea for it to rely based on the format of the what is currently set for the component.

@AuspeXeu
Copy link
Collaborator

AuspeXeu commented Feb 5, 2016

Couldn't we use the format setting to generate a regex from that, what do you think?

@SoLoHiC
Copy link

SoLoHiC commented Apr 27, 2016

👍

1 similar comment
@gf3
Copy link

gf3 commented May 17, 2016

👍

@davidpatters0n
Copy link
Contributor Author

@AuspeXeu - The tests on Travis are going to continue to fail because of this PR: #571 - As mentioned in the comment for that PR i have opened a separate PR that addresses this too.

WRT to your comment:

Couldn't we use the format setting to generate a regex from that, what do you think?

I didn't need to do this because I made use of: nonpunctuation instead which works just as well.

@davidpatters0n davidpatters0n force-pushed the bug/prevent-bad-characters branch from 591df69 to df971e4 Compare December 9, 2016 16:06
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants