tracker issue : CF-3859758

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

isDate('16.51p') eq true

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): Tom Chiverton / Tom Chiverton (Tom Chiverton)

Created: 12/01/2014

Components: Core Runtime

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / Some users will encounter

Locale/System: ALL / Linux All

Vote Count: 6

Problem Description:
isDate() validates as true obviously invalid dates.

Steps to Reproduce:
Case 1: <cfoutput>#isDate('16.51p')# #dateformat('16.51p')#</cfoutput>

Case 2: isDate('9.69p') eq true

Actual Result:
YES 16-May-14 

Expected Result:
NO and an exception

Any Workarounds:

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

Watson Bug ID:	3859758

External Customer Info:
External Company:  
External Customer Name: ChivertonT
External Customer Email:  
External Test Config: My Hardware and Environment details:



There could be a case made for it being a time, but it isn't a date format used anywhere in the world as far as I know. It *might* be castable to a date inside ColdFusion, but that isn't a good reason to keep this.
Comment by External U.
9851 | December 01, 2014 04:51:52 AM GMT
Agree with Tom. The function is useless if it does type coercion to try to get a "yes" (sic) answer. "16.51p" is not a date.
Comment by External U.
9852 | December 01, 2014 05:27:22 AM GMT
+1 /////////////////////////////////////
Vote by External U.
9873 | December 01, 2014 05:27:32 AM GMT
We use "." as month,day, year delimiter.. "[ ]*[\\. ,/-][ ]*"; p is also a valid suffix for pm. There is some risk if we change the regex.
Comment by Awdhesh K.
9853 | December 02, 2014 03:27:59 AM GMT
+1 ..............................................
Vote by External U.
9874 | December 03, 2014 07:18:08 AM GMT
Yes, it's clear your entire way of going about this validation is ill-conceived. What sort of closure status is "too many changes". That's basically "too much work". I know you guys are work-averse, but you should be so readily admitting it. You've implemented something poorly, and now it's biting you on the bum. Well: biting US on the bum. You need to take responsibility for your own actions, and deal with situations like this.
Comment by External U.
9854 | December 04, 2014 01:38:21 AM GMT
Adobe; you are kidding me. You may use "." as a month/date/year separator, but there is only one seperator, so it can't be a full date can it ? If CF is also then taking the '51p' as the time part, that's also very wrong, because no matter what date you resolve the '16.' to, '51pm' is not a valid hour. This is backed up by isDate('51p') eq NO so your implementation is inconsistent with the position you advocate here. I find it hard to understand how there are 'too many changes' to adding a single regular expression to the front of your isDate() implementation.
Comment by External U.
9855 | December 04, 2014 03:39:45 AM GMT
Fix this, please. \\\\\\\\\\\\\\\\\\\\\\\\\\\\
Vote by External U.
9875 | December 04, 2014 08:56:08 AM GMT
I agree in principle with the Adam and Tom. Adobe is too aggressive with trying to accommodate date/time fragments. Maybe we need an IsTime() function to validate time-only strings, and only have IsDate() return true for valid dates or full date/time strings. In any case, ColdFusion does way too much "hand-holding" when it deals with loosely typed variables, trying to allow/convert even absurd edge-case values with all of the IsXXX() functions.
Comment by External U.
9856 | December 04, 2014 09:47:46 AM GMT
+1. Please reopen and address this properly. Aside from the minds of Adobe, there is no circumstance on the planet where 16.51p = May 16, 2014
Vote by External U.
9876 | December 04, 2014 12:15:14 PM GMT
+1 ......................
Vote by External U.
9877 | December 05, 2014 06:46:55 PM GMT
Interesting.. //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) Can this ticket please be re-opened to fix these 5 issues? Thanks!, -Aaron
Comment by External U.
9857 | December 05, 2014 08:19:09 PM GMT
We are re-opening this bug and marking it ToFix.
Comment by Nimit S.
9858 | December 08, 2014 09:32:34 AM GMT
Cheers Nimit. Please consider a coupla points here: 1) this is an isDate() function, not a canPossiblyBeCastToADateInDefianceOfAllCommonSense(). It doesn't need to - and shouldn't! - accept absolutely anything, and return "yes". It should only return "yes" for a format that legitimately can be considered a date in the current locale; 2) don't worry about backwards compat considerations. If anyone is leveraging the BUGGY behaviour this function currently has: they have brought this upon themselves. It is better for a few users to be inconvenienced (and it be through their own poor decisions), than for this function to - basically - be useless. This is not an exercise in pleasing everyone, it's an exercise in making the function work in a way that is logical, predictable, useful, and does what it says on the tin. I think it would be a good idea if you shared your plan for what is and is not going to be considered a "yes" value here, and engage the community in agreeing on the solution (again, remembering it's not an exercise in pleasing *everyone*. Cheers. -- Adam
Comment by External U.
9859 | December 08, 2014 11:52:34 AM GMT
At the very least, can you list the formats (by locale) that you are thinking of accepting as legitimate for this function. Cheers.
Comment by External U.
9860 | December 08, 2014 12:27:54 PM GMT
This is awesome news, that shows Adobe still want to fix (maybe long standing !) bugs in the platform. Hopefully #CF-3862961 will also be fixed as it's basically the same issue ?
Comment by External U.
9861 | December 08, 2014 02:54:03 PM GMT
Hi Tom, I will closing that bug as duplicate. We will track that bug as part of this bug.
Comment by Nimit S.
9862 | December 08, 2014 10:13:38 PM GMT
+1 because it should work!
Vote by External U.
9878 | June 30, 2015 04:26:16 AM GMT
What's going on with this, Adobe?
Comment by External U.
9863 | June 30, 2015 04:29:04 AM GMT
As ridiculous as this bug sounds, the decision made is to not fix this bug. My first reaction to this bug was to fix it somehow. We then had a detailed discussion with the engineers and the architect involved to realize the impact of such a fix. The engineers feel this too risky a fix. Such a fix cannot be made in isolation as it has a much wider impact to the other existing parsing rules of the isDate function which can break functionality. Considering the impact on existing behavior, we will not be fixing this bug.
Comment by Rakshith N.
9864 | September 25, 2015 12:09:06 AM GMT
Cheers for the thorough feedback, Rakshith. I'd be keen to hear in more detail why fixing this was deemed "too risky". Not in general terms, but in real world technical terms, with an indication of how you did the risk assessment. I say this because sometimes your guys invent completely theoretically reasons to not do work, but don't really assess how actually likely the theoretical reason is to actually exist. And please make sure the docs get updated to reflect there's a known-issue though, yeah?
Comment by External U.
9865 | September 25, 2015 01:44:18 AM GMT
If isDate() is going to be broken-to-the-point-of-useless, then the documentation *must* point out this fact, including examples of what strings isDate() will return true and false for - basically a dump of your test cases.
Comment by External U.
9866 | September 25, 2015 02:39:09 AM GMT
Having done some investigation here, it's not really isDate() being incorrect here. It's just what CF will consider a date. isDate() is telling the truth here... one can use '16.51p' as a date. Like in dateFormat(), dateAdd(), dateDiff() etc. It parses to {ts '2015-05-16 00:00:00'} How? I don't know. I think Adobe need to explain this. The problem actually lies in that ColdFusion should NOT consider '16.51p' to be a date. It's not. There is no world in which that is a date on any description, let alone a representation of May 16, 2015. So, Rakshith can you or one of your devs explain what's going on here? Cheers.
Comment by External U.
9867 | September 25, 2015 02:53:21 AM GMT
Please reopen and fix this.If this was isTime() ok, but 16.51p is NOT a date.
Comment by External U.
9868 | September 25, 2015 05:54:45 AM GMT
We possibly need a new ticket then, to ensure "16.51p" isn't - ever - considered a date? Adobe, thoughts?
Comment by External U.
9869 | September 25, 2015 05:58:52 AM GMT
Hi Rakshith, Thanks for the feedback. I agree this should be fixed. Otherwise, we'll be at CF v20 and still have stuff like this lurking around. I'd have CF12 stay true to its intent on breaking backward-compat. And let's get stuff like this cleaned out. Thanks!, -Aaron
Comment by External U.
9870 | September 30, 2015 03:06:58 PM GMT
+1 to Adam's question. This issue needs to be fixed one way or another. Thanks!, -Aaron
Comment by External U.
9871 | December 05, 2015 04:19:20 AM GMT
+1 to fixing this in ColdFusion 12, backward-compatibility be darned. Rip the band-aid off now and get it over with.
Comment by External U.
9872 | December 05, 2015 08:31:27 PM GMT