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.
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.
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
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.
cc:
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.
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.
Hi@john.cowles , this request is under consideration, we are currently trying to identify the best solution for this use case and soon we will start the development.Will keep you posted on the ETA.
Thanks,
Shambhawi