tracker issue : CF-4102485

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

[ANeff] ER for: isValid() support for ISO 8601

| View in Tracker

Status/Resolution/Reason: To Fix//

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

Created: 12/22/2015

Components: Language

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Win All

Vote Count: 2

There should be an isValid() check to ensure a string is in ISO 8601 format.

Example:

<cfscript>
  dateTime = createDate(2016,1,3);

  isoDate = dateFormat(dateTime, "iso");
  isoTime = timeFormat(dateTime, "iso");
  isoDateTime = dateTimeFormat(dateTime, "iso");

  writeOutput(isValid("isodate", isoDate));//would return true (per this ER)
  writeOutput(isValid("isotime", isoTime));//would return true (per this ER)
  writeOutput(isValid("isodatetime", isoDateTime));//would return true (per this ER)
</cfscript>

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

Watson Bug ID:	4102485

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

Attachments:

Comments:

The fix would involve validating date to be in ISO format.
Comment by Immanuel N.
4982 | December 22, 2015 05:56:50 AM GMT
+1 .................................
Vote by External U.
4994 | December 22, 2015 07:34:08 AM GMT
Hi Immanuel, For date, time and date+time? All 3? Thanks!, -Aaron
Comment by External U.
4983 | December 22, 2015 04:53:46 PM GMT
What is the reason for needing to do this? IE: what real world problem are you needing to solve by making Adobe do this? Consider this pseudo-code: if isValid("isoDate", someValue) do x else do y what would x be as opposed to y? Why would you need to know this, and why would it be sufficiently ubiquitous a requirement that it warrants making Adobe do the work to implement it? This sounds like time wasting to me.
Comment by External U.
4984 | December 23, 2015 01:25:41 AM GMT
Hi Adam, Probably the same as some of isValid()'s other checks. To ensure the string is properly formatted before storing or sending it somewhere. Thanks!, -Aaron
Comment by External U.
4985 | December 23, 2015 04:01:25 AM GMT
Not a theoretic "what if", but the actual use case in front of you when you raised the ticket. What *real* pain point were you experiencing which had you conclude it would be beneficial for Adobe to sink time into doing this? The validation should be applied before you use the thing in a way that *won't work* unless the thing is the format specified. For example validating something is an integer before *your code* then goes an uses it as an integer, or something is able to be coerced into a boolean before being used in a conditional. For the record, I don't think validations like "social_security_number" are appropriate in CFML, as there is no subsequent CFML usage which will break if the string is not in that particular format. I think the same applies here. There is no CFML code that relies on a string being in ISO 8601 format, and intrinsically that (that an ISO 8601-formatted string should be parseable as a date would fall under the remit if isValid("date")). Therefore there is no reason to have a special validation treatment for that string format. Basically for CFML to be validating for something that could be a valid "type", then that type needs to actually exist in CFML as a concept: eg a string which will be coerced into a date, or an XML doc, or deserialised as JSON etc.
Comment by External U.
4986 | December 23, 2015 04:17:41 AM GMT
Hi Adam, To verify a string received from one API is valid ISO 8601 before sending it to another API that requires that format. That is a use case I actually deal with. Thanks!, -Aaron
Comment by External U.
4987 | December 23, 2015 04:28:03 AM GMT
That, then, would be the job of the relevant APIs, not CF acting as the routing between the two. The business rules that the string as a specific format belong to the APIs, not your code in this case. *your code* doesn't have any requirement that the strings are ISO8601 format, by the sounds of it.
Comment by External U.
4988 | December 23, 2015 04:40:07 AM GMT
Oops... hadn't finished. You shouldn't be second-guessing the value from the first API, if it's supposed to be in that format, then it's broken if it's not that format. Do you test if it says it's gonna send an integer that it actually *does* send an integer? An API is a contract, so one ought to accept it's gonna stick to the contract. This is different from data that comes into your app from a user-filled form or other human interaction. Yes, you ought to validate that obviously. But if you were asking humans to type in a ISO 8601 string, you should probably be shot ;-) If your code actually needed the value to be in that format or it would fail, then yeah you'd need to validate for that. But surely the validation then would be "is it a date", not "is it specifically an ISO 8601 formatted string". I think this would fall into a situation of your own manufacture, and it's for you to deal with. If *your code* was responsible for providing the data in ISO 8601 format to the receiving API, then you need to do your work diligently and make sure it fulfils its side of the contract. So you'd have a unit test which checks the "format as ISO 8601" method. I dunno if it's really Adobe's burden to provide the validation function for you there, but that would be at least a realistic use case. As you're piping data from one API to the other, the best way to deal with this is to simply pass the data to the second API and watch it fail if it doesn't like it. If the source API is not fulfilling its contract, it's for them to fix. And if it can;t be fixed and you really do need to check it "manually", this still amounts to a very very minor use case. Sux for you... but not for Adobe to deal with, IMO.
Comment by External U.
4989 | December 23, 2015 04:55:24 AM GMT
Hi Adam, After fetching from 1st API, the fields are logged to db. At the time of fetching the fields from db to send to 2nd API, the values are checked to ensure nothing has been manipulated. It's not a direct pipe from one to the other. Thanks!, -Aaron
Comment by External U.
4990 | December 23, 2015 05:16:04 AM GMT
BTW, apologies for the short replies. My "work day" is done and not at the computer now. I'll have to continue in a few hours. Thanks!, -Aaron
Comment by External U.
4991 | December 23, 2015 05:17:18 AM GMT
When consuming JSON data, a recommended date format is ISO8601 "extended" (for many valid reasons outlined at http://stackoverflow.com/a/15952652/693068 ) When generating a CSV files for use in Excel (because CFSpreadsheet is too slow or hits a JVM Heap limitation), ISO8601 is the best date format to use for consistent automatic date detection (at least in the versions of Excel that I've been testing. Using any other format can result in randomized display formats.) When importing these strings as dates values into a database, it'd be nice if date functions treated & parsed ISO8601 extended strings as valid date values. This would enable CFQUERYPARAM to function without having to first parse/convert. (NOTE: ISO8601 "Basic" format YYYYMMDD may be wrongly interpreted as an integer or a epoch/Unix timestamp.) <cfset myISOString = "2015-12-23T07:06:00"> <cfqueryparam value="#myISOString#" cfsqltype="CF_SQL_TIMESTAMP" null="#YesNoFormat(NOT isDate(myISOString))#"> A feature like this would be better as a community-drive UDF so that developers aren't negatively impacted by any overlooked features and/or required to wait & purchase new major version licenses for bug fixes.
Comment by External U.
4992 | December 23, 2015 09:49:04 AM GMT
@James. Yes. So this is a case for ISO-8601 strings being usable in date parsing functions. So that's an isDate() check. But this is not relevant to this ticket. In this context it *doesn't matter* that it's an ISO-8601-formatted date/time string, or any other sort of string format CF handles. It just has to parse as a date. So it doesn't need to be validated as being - specifically - ISO-8601 format. @aaron: yeah, what you describe is, in that case, a legit use case. Too edge-ish to be a basis for this work IMO, but my opinion there has been reflected already in my lack of voting for it.
Comment by External U.
4993 | December 23, 2015 10:09:05 AM GMT