Dates beyond 12/31/9999 are considered "valid", yet crash or result in data loss.| View in Tracker
Reporter/Name(from Bugbase): James M. / ()
Failure Type: Crash
Found In Build/Fixed In Build: 2016,0,11,314546 /
Priority/Frequency: Normal / Most users will encounter
Locale/System: English / Win 2016
Vote Count: 0
Problem Description: There are issues regarding isDate(), isvalid("date") and CreateODBCDate() with ColdFusion 2016 & 2018. I've posted more info here: https://gamesover2600.tumblr.com/post/186477080549/coldfusion-dates-mdyyyyyyyyy What are the use cases to allow dates greater than "12/31/9999"? Dates values exceed this will throw errors or lose data when saved to a database using the "date" data type. Steps to Reproduce: Validate the following dates using isDate(), isValid("date") and CreateODBCDate(). 12/31/9999 7/22/22019 12/31/292278993 9/9/292278994 Actual Result: CF2016 ERROR: States "9/9/292278994" isn't a valid date, but modifying month/date values will make it similar dates valid. Adding 1 day to 9/8/292278994 will validate "9/9/292278994" as true even though it wasn't valid when passed directly. CF2018: Currently All dates are considered "valid" CF2018 CRASH: CF2018 throws a hard unstoppable error (ie, crash) when converting 12/31/292278993 using CreateODBCDate(). CF2016/20188 DATA LOSS: Upon setting to a cell in CFQuery, all digits beyond the thousands place are truncated. Expected Result: 12/31/9999 is the only real date that is capable of being consistently validated as a date in other systems and stored in a SQL database without truncating leading year digits. Any Workarounds: Write your own logic w/date range limits and avoid using the built-in isDate() & isValid("date") functions.