tracker issue : CF-4204879

select a category, or use search below
(searches all categories and all time range)

Dates beyond 12/31/9999 are considered "valid", yet crash or result in data loss.

| View in Tracker

Status/Resolution/Reason: Open//

Reporter/Name(from Bugbase): James M. / ()

Created: 07/22/2019

Components: Functions, Datetime

Versions: 2016

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:

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().

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.



I attempted to use the DATEDIFF function in Excel with a valid futuristic date to calculate the difference in days and it fails and returns "#VALUE!". What use is a valid date if it can't be used reused anywhere else? I checked out and they don't generate calendars past the year 3999, so they're even more restrictive than SQL's 9999 maximum year.
Comment by James M.
31070 | July 24, 2019 12:02:22 AM GMT