My response to this blog post was detected as spam, so I'm responding here.
The recommendation from Adobe has been to use isValid("date") instead of isDate(). If
TRUE, you should also test using
isValid("date") and use parseDateTime (with try/catch) to see what ColdFusion actually evaluates as the date. In my opinion, a value isn't a valid date until it can be correctly parsed and then sent to third-parties and also be parsed as a date (ie, SQL).
For example, tested with latest CF2016
isDate(2000); /* NO */ isValid('date',2000); /* YES */ parseDateTime(2000); /* CF Error */
A year ago,
12/31/292278993 was considered a valid date by Adobe ColdFusion.
More info here:
(ACF also returned
isvalid("integer", 2147483648) and a value like
Here are some test date strings that I've used to compare ColdFusion date parsing against a client-side DateJS library that I use.
Top comments (2)
Apart from the American ordering to the month and the date, why isn't
12/31/292278993a date? I'll admit that we probably won't be using the same calendar system in 292278993, but we don't know what it will be, so why not stick with the one we know?
We may need to deal with this before 12/31/9999. The current max date for MSSQL SqlDateTime while java is 12/31/999999999. Luckily none of my clients are asking to schedule anything that far out in advance "yet".
What would it take to get all related technologies to agree on a standard? (ie, the current max date for java is 12/31/999999999.)
A recent project had a high lifetime membership calculation bug. Instead of entering "birthdate", the customer entered "current age". Server-side isDate() returned "yes" that the integer was a valid date, but couldn't perform a DateDiff() using the "valid date". To fix, I added a check using isValid("usdate", birthdate).