tracker issue : CF-4079616

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

[ANeff] ER for: THIS.strictDateValidation

| View in Tracker

Status/Resolution/Reason: Needs Review//

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 10/27/2015

Components: Core Runtime

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 2

isDate() isn't reliable (please see 3859758 and numerous others), so something should be done.

This ER is to add a THIS.strictDateValidation boolean Application.cfc setting (and same for Application.cfm) such as was done for THIS.strictNumberValidation.

Default would be false, for backward-compat to accept non-date values. If true, then isDate() only returns true for a valid date.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4079616

External Customer Info:
External Company:  
External Customer Name: Aaron Neff
External Customer Email:

Attachments:

Comments:

I think it should be a server level setting (ie: only changeable via XML file), and the default should be TRUE. If people actually leverage the poor existing implementation they can make the change. Let's think more about the future, rather than navel-gaze at the past.
Comment by External U.
5438 | October 27, 2015 03:43:54 AM GMT
(sorry, meant to also add) my rationale is that we shouldn't need a setting to make the thing work properly. If people need to make things work in a historically poorly implemented way, then they action should be on *their* part, not everyone else's.
Comment by External U.
5439 | October 27, 2015 03:45:57 AM GMT
Hi Adam, Sure! A server-level setting does sound best. And yeah I agree w/ the default being TRUE and your rationale for that. I wish we didn't even need a setting. But.. it looks like Adobe isn't going to fix this any other way.. so figured I should log this. I figured I'd either log this ticket, or create a scheduled task that auto-creates an "isDate() is busted" ticket every couple weeks =) Thanks!, -Aaron
Comment by External U.
5440 | October 27, 2015 07:03:53 AM GMT
I agree with Adam's take on this. Default to true and make it a server-level setting.
Vote by External U.
5443 | October 27, 2015 08:50:10 AM GMT
I agree that the current implementation of IsDate() is completely unfit for purpose and can't be used reliably. I can't imagine there are that many users/applications out there that rely on the broken behavior, so "strict" should be "always on" unless a person has to dig into ColdFusion Administrator to change it.
Comment by External U.
5441 | October 27, 2015 08:54:39 AM GMT
+1.....default to true makes perfect sense.
Vote by External U.
5444 | October 27, 2015 11:16:53 AM GMT
Adobe, To illustrate that the current broken behavior can't even be leveraged (so there's 100%* not-a-chance that anyone's leveraging it), here's my 5:49:09 PM GMT+00:00 Dec 5, 2014 comment from CF-4079616: -------------------------------------------- //returns May 16, 2014 01:00:00 PM writeOutput(dateTimeFormat("16.51p", "mmmm dd, yyyy hh:nn:ss tt")); //thus, in "51", "5" is month and "1" is hour //returns December 16, 2014 01:00:00 PM writeOutput(dateTimeFormat("16.121p", "mmmm dd, yyyy hh:nn:ss tt")); //thus, in "121", "12" is month and "1" is hour So.. what if we add a space, to force "1" as month and "21" as hour? //returns January 02, 2016 01:00:00 PM writeOutput(dateTimeFormat("16.1 21p", "mmmm dd, yyyy hh:nn:ss tt")); //nope, LOL, CF is allowing date to have mixed delimiters and treating "16.1 2" as the date and "1p" as the time Thus, existing code is not using these strings as dates b/c it is unreliable. Thus, fixing the following 5 issues would not break existing code: 1) CF's regex should require a space between the date portion and the time portion 2) CF's regex should not allow the date portion to contain mixed delimiters 3) CF's regex should only allow a ":" in the time portion between hour, minute and second 4) CF's regex should only allow a "." in the time portion if hour, minute and second are specified and the "." preceeds the milliseconds 5) CF's regex should only allow a " " (space) in the time portion if hour (minute and second optional) is specified and the " " preceeds the time marker string (a, p, am, pm) -------------------------------------------- * - I say 100%, but.. I suppose w/ enough will power someone may be able to work around this?? I'd say that code deserves to break =P Thanks!, -Aaron
Comment by External U.
5442 | October 27, 2015 01:51:09 PM GMT