Title:
Dates beyond 12/31/9999 are considered "valid", yet crash or result in data loss.
| View in TrackerStatus/Resolution/Reason: To Fix//BugVerified
Reporter/Name(from Bugbase): James M. / ()
Created: 07/22/2019
Components: Language, DateTime Functions
Versions: 2016,2018
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.
Attachments:
Comments: