tracker issue : CF-4067016

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

isDate returns true for a float that looks similar to a date but does not use uniform delimiters.

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/Duplicate

Reporter/Name(from Bugbase): Cory Silva / Cory Silva (Cory Silva)

Created: 09/30/2015

Components: Language

Versions: 11.0

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Linux

Vote Count: 3

Duplicate ID:	CF-3859758

Problem Description: isDate returns tree for a float that looks similar to a date but does not use uniform delimiters.

Steps to Reproduce: isDate("7,022.00");

Actual Result: true

Expected Result: false

Any Workarounds: Check string for the existence of both a comma and a period; no (to my knowledge) date formats use both.

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

Watson Bug ID:	4067016

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

CentOS 7

Attachments:

Comments:

Ran into this using JSONUtil
Comment by External U.
5660 | September 30, 2015 01:24:04 PM GMT
+1 please fix it this time........
Vote by External U.
5665 | September 30, 2015 02:31:12 PM GMT
+1 - This and CF-3859758 need fixed
Vote by External U.
5666 | September 30, 2015 04:16:49 PM GMT
+1. Only formats in the current or a specified locale should be used by this function (and other string->date functions). Not any old hotch potch of options, which pretty much render the function useless.
Vote by External U.
5667 | October 01, 2015 12:36:01 AM GMT
Can we have details of how the fix will be implemented, pls? Cheers.
Comment by External U.
5661 | October 20, 2015 08:07:40 AM GMT
Current DateParser is some limitation
Comment by Awdhesh K.
5662 | October 23, 2015 12:00:36 AM GMT
Be that as it may, the question was how you were implementing it, now whether it had challenges ;-) I recommend before you start parsing the thing as a date, you do pattern validation on the input string, and reject it if it doesn't match a valid pattern.
Comment by External U.
5663 | October 23, 2015 12:14:26 AM GMT
Awdhesh Kumar, Thank you for the update. Are there plans to remove these limitations or add a way around them. Perhaps: /** * @param {*} date * @param {boolean} [isStrict] defaults to false for backwards compatibility... */ isDate(date, isStrict) { // Parse date logic }
Comment by External U.
5664 | October 23, 2015 08:50:54 AM GMT