tracker issue : CF-3859758

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.

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.

+1 /////////////////////////////////////

Vote by External U.

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.

+1 ..............................................

Vote by External U.

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.

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.

Fix this, please. \\\\\\\\\\\\\\\\\\\\\\\\\\\\

Vote by External U.

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.

+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.

+1 ......................

Vote by External U.

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.

We are re-opening this bug and marking it ToFix.

Comment by Nimit S.

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.

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.

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.

Hi Tom, I will closing that bug as duplicate. We will track that bug as part of this bug.

Comment by Nimit S.

+1 because it should work!

Vote by External U.

What's going on with this, Adobe?

Comment by External U.

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.

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.

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.

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.

Please reopen and fix this.If this was isTime() ok, but 16.51p is NOT a date.

Comment by External U.

We possibly need a new ticket then, to ensure "16.51p" isn't - ever - considered a date? Adobe, thoughts?

Comment by External U.

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.

+1 to Adam's question. This issue needs to be fixed one way or another. Thanks!, -Aaron

Comment by External U.

+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.