Rules Engine: Tokenized Dates should display as stored in the system

I am storing date data in an MDA table in MM/DD/YYYY format, but when I use that field as a token in a CTA, it’s displaying as YYYY/MM/DD.  It should display the way it is stored in the system.

 

 

 

 

 

 

+1.

And not only that format change.
Found the differences between showing the date in Rule preview mode vs Report.

The data stored in MM/DD/YYYY format but when we preview the data in Rule Fetch it is displayed as MM-DD-YYYY.

Screenshot from Report Builder

Screenshot from Rule Preview:

Thanks.

@darkknight  what is your user locale? How does the date appear when you view it in a report?   
cc: ​​​​@sriram pasupathi 

@rakesh I was at a different company when I logged this request, so I do not know what the locale was - but I still think it is a valuable ask.  The screenshot above shows how the date was rendering in a report….like MM/D/YYYY

@darkknight Since the date is tokenized and converted to a text, it cannot be dynamically changed as per the user locale. The report builder respects the user locale. That’s why there is a discrepancy. So, even if we take the rule creator’s user locale during tokenization, you might still have a discrepancy if there is a mismatch between your locale and rule creator’s locale.

@darkknight did you get a chance to view the comments here?

@sai_ram  @sriram pasupathi I don’t understand.  In the example I cited (which was at a previous company so I don’t have access to it today) the data was stored in MDA in the format MM/DD/YYYY.  The rule / tokenization changed the format to YYYY/MM/DD.  

That should have nothing to do with the user locale.  The Tokenization process should respect the value and format of the source field.

I just contacted Gainsight Support about this issue as all of our date fields used in Rules Engine, even the Transformation Rule Date formula field, are being reformatted to YYYY-MM-DD.  This was the reason provided:

“As per the code/design when you add a date field as a token to any type of action in the rule, the end result is auto-populated in YYYY-DD-MM format. This is how the rule is designed.
 
You may ask us why we cannot populate the format as it is in the source. To answer this, the reason for populating the date values in YYYY format is, that we have multiple customers and each customer is based in different regions and the source can have different time zone-related date fields.
 
So, As per the code, during execution, the rule just gets the data from the source for the date field and it converts to the default YYYY-DD-MM format.”

Having dates formatted differently on a single CTA record view (date fields vs text fields) is a bad end user experience.  The rule should respect the source format or we should have the ability to set the default format at the rule level.  

@rakesh we had some plans around this?

Is there a update on this one?  

We just ran into this one and it is causing a inconsistency in dates on a CTA for us.  The CTA due date and created date are showing in one format (MM/DD/YYYY) and the tokenized date shown in the CTA comments is a different format (YYYY-MM-DD).  It is confusing and especially with our EMEA team who utilizes a different locale date than we do in the US.  I would expect all dates shown in all places as the locale date.