-
Type:
Enhancement
-
Status: In Development
-
Priority:
Medium
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: BenAdmin
-
Labels:None
-
Module:BenAdmin - Import
-
Reported by:Client
-
Item State:Development - On Hold
-
Issue Importance:Q2
-
Sprint:WT Sprint 38 - Enhancement, WT Sprint 40 - Enhancement
-
Severity:Simple
Please refer to WT-8848.
We support date formats - which appear to be redundant (see first two) and incomplete.
MM/DD/YYYY
MM-DD-YYYY
YYYY/MM/DD
YYYYMMDD
But not - which is one of the standard US date format.
MMDDYYYY
This date format picker needs to be rationalized to allow following regular expressions where * stands for any special character. In fact the list can be further pruned if the system could parse the string to remove special characters first and then we interpret it for only three options.
MM*DD*YYYY
MMDDYYYY
DD*MM*YYYY
DDMMYYYY
YYYY*MM*DD
YYYYMMDD
CC Nathaniel Cornejo-Walker Cindy Wibbing Nagini Indugula Bharti Satpute Amit Thorve
- relates to
-
WT-8848 City National Bank import failure
-
- Closed
-
We have not yet planned this. Adding a new Date format may not take much efforts. But here as we need rationalization for date format, high efforts are needed.
Currently we are running short of bandwidth. If possible we can add the MMDDYYYY format for now which is requirement and take rationalization which is betterment once enough bandwidth is available. Please let us know the priority.
Hi Abhay Patil,
Today, I discussed this with Amit Thorve. We have concluded that it will create confusion with using *. We also have to fix and take as input the replacement of *. This may create confusion for end user, as there is already on field for null replacement character on template settings.
Amit Thorve has suggested that instead of doing this, provide below combinations on template settings,
MM/DD/YYYY
MM-DD-YYYY
MMDDYYYY
DD/MM/YYYY
DD-MM-YYYY
DDMMYYYY
YYYY/DD/MM
YYYY-DD-MM
YYYYDDMM
YYYY/MM/DD
YYYY-MM-DD
YYYYMMDD
Please let us know your thoughts on this.
Hi Abhay Patil
Any update on this?
I believe that this has to be SIMPLE - and we can definitely make it NOT CONFUSING. Following is my suggestion. However I leave it to Nagini Indugula and Jennifer Reed to figure in consultation with you and Amit Thorve.
We can have only following four options.
MM/DD/YYYY
DD/MM/YYYY
YYYY/DD/MM
YYYY/MM/DD
Then each option should be liberally interpreted by code as one that can have any separator or no separator.
So for example, the option "MM/DD/YYYY" should admit and correctly interpret all of the following as July 25, 2017.
07/25/2017
07-25-2017
07252017
The way it could be coded is - whenever there is a data item of type "date", the system should first remove any special characters - leaving only numerals that take 8 spaces. Then it can be parsed using the sequence in the format.
Once again - I leave it to product management to make the call.
Hi Jennifer Reed,
Could you please let us know the thoughts of the product team on this.
We need to update the status of the ticket
Regards
Gaurav
Gaurav Sodani (Inactive)
added a comment - Hi Jennifer Reed ,
Could you please let us know the thoughts of the product team on this.
We need to update the status of the ticket
Regards
Gaurav
Satya Abhay Patil Jaideep Vinchurkar - please go ahead with Amit's suggestion.
Hi Snehal Katkar,
Please refer attached test cases.
Please let me know if any additional scenario's are required. Testcases.xls
Also, while testing If found some additional scenario will update in test cases accordingly.
Thanks,
Jayshree
cc : Rakesh Roy Prasad Pise
Jayshree Nagpure (Inactive)
added a comment - Hi Snehal Katkar ,
Please refer attached test cases.
Please let me know if any additional scenario's are required. Testcases.xls
Also, while testing If found some additional scenario will update in test cases accordingly.
Thanks,
Jayshree
cc : Rakesh Roy Prasad Pise 
Suraj Sokasane Do we have an update on the status of this ticket?