Strict validation is being forgiving #1196

johnstrickler opened this Issue Oct 16, 2013 · 6 comments


None yet
4 participants
moment('2012-05-25', 'YYYY-MM-DD', true).isValid();        // true
moment('201-05-25', 'YYYY-MM-DD', true).isValid();         // true
moment('20-05-25', 'YYYY-MM-DD', true).isValid();          // true
moment('2-05-25', 'YYYY-MM-DD', true).isValid();           // true

I would expect the last 3 lines to be false.


icambron commented Oct 16, 2013

In the current implementation, the strict parser makes sure that all the tokens are used and they consume all the text, but the tokens themselves are still forgiving. For example, "YYYY" matches 1-4 digits.

@ichernev - you mentioned once that we might want separate token definitions for strict. What do you think?


ichernev commented Oct 16, 2013

Well, if we want to move forward from a hacky implementation that sort of works to something better, yes, we do need separate tokens. I'm pretty sure there was a reason why not to use parse -> format -> check for equality, but I can think about one right now.


icambron commented Oct 17, 2013

I just meant having alternative versions of parseTokenFourDigits and company.

FYR: Corresponding jsfiddle

Current workaround:

moment('12/31/2013', 'MM/DD/YYYY', true).isValid() && 
              moment('12/31/2013', 'MM/DD/YYYY').get('y').toString().length == 4;

Comment if there is anything simpler.

Here's an alternative workaround (less robust but simpler):

moment('12/31/2013', 'MM/DD/YYYY', true).isValid()  && /\d{4}$/.test('12/31/2013')

icambron referenced this issue Nov 25, 2013


Strict tokens #1303

ichernev closed this in #1303 Nov 26, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment