UUID recognized as a date

[jwhitehorn]

I happened across this by chance, but it's a very real scenario for me in a production application. Moment.js, when passed a specific UUID, believes it to be a date. (presumably other UUIDs are mistaken for dates as well, but this was the one I happened across)

Here's an example;

> moment('5917238b-33ff-f849-cd63-80f4c9b37d0c').toDate()
< Sun Aug 26 5917 00:00:00 GMT-0500 (CDT)
> moment('5917238b-33ff-f849-cd63-80f4c9b37d0c').isValid()
< true

Compare that with just about any other UUID, and the result is what I'd expect;

> moment('5e7af008-b108-40bb-ae8d-50ea223a8219').toDate()
< Invalid Date
> moment('5e7af008-b108-40bb-ae8d-50ea223a8219').isValid()
< false

From an expectation standpoint, I'd expect all UUIDs to return false for isValid. The erroneous condition actually causes my application to run with the date Aug. 26 5917, as it assumed the user was trying to input a date 😮

I've confirmed this behavior in both 2.11.0 running on Node.js, and 2.11.2 running in Chrome - same behavior in both platforms.

[maggiepint]

This is happening because the GUID leads with 7 digits. This causes the regular expression for the ISO8601 date format YYYYDDD to match.

You can avoid this by parsing in strict mode using the ISO_8601 constant:

moment('5917238b-33ff-f849-cd63-80f4c9b37d0c', moment.ISO_8601, true).format()
"Invalid date"

This means that the dates you are passing in must exactly match an ISO8601 format, which may not be the case for your application. You might also consider multiple format parsing with strict mode, if you have multiple known formats but they can be enumerated:

moment('01/01/2015', ['M/D/YYYY', 'YYYY-MM-DD'], true).format()
"2015-01-01T00:00:00-06:00"
moment('2015-01-01', ['M/D/YYYY', 'YYYY-MM-DD'], true).format()
"2015-01-01T00:00:00-06:00"
moment('5917238b-33ff-f849-cd63-80f4c9b37d0c', ['M/D/YYYY', 'YYYY-MM-DD'], true).format()
"Invalid date"

The behavior that you are seeing is actually already documented as a bug in #2985. I know this looks dissimilar, but both issues boil down to the characters after the matched regular expression being ignored.

I'm going to close this issue since it matches the other bug, but feel free to let us know if you need more help with making things work.

[jwhitehorn]

Thank you for the clarification, I had assumed it was something similar to what you described. I'm glad to hear it's already on your radar.