Timestamp bug in utterances data

REQUEST FROM CLIENT (SLICE):

We use utterances API for getting user activity to our database The DateTime format used to be 2022-08-15T00:00:12.798Z. We are now getting DateTime in multiple formats from Nov 10th:

Tue Nov 15 2022 8:00 AM
2022-10-15 08:00:00

Can we make this format consistent to 2022-08-15T00:00:12.798Z

Hi @Manish_Pushkar

This seems like a feature/task request
Please follow the guidelines and raise an internal ticket

Hi @gautham
Thanks for your response.
As mentioned, this is not a feature request. This particular format (2022-08-15T00:00:12.798Z) is how the data was displayed in earlier. Since the 10th Nov, that’s somehow changed to a different format.
The client’s ask here is to just ensure that the data is displayed in the older format.
Let me know what can be done about this.

Hi @shahnawazsur @Manish_Pushkar - the changes were made to make the timestamp more readable on the export. Could you share the issues you’re facing due to this?

1 Like

Hi @Sanskrity, thanks for your response.
While I understand your point, client is irate that this happened and are adamant on reverting back to the format. Let us know the next best steps to tackle this.

Hi @shahnawazsur - please check what the client is unable to achieve while working with the new format. If there are certain issues occurring in analysis of data, then we’ll evaluate that.

@Sanskrity - Have updated the client after having spoken with @Manish_Pushkar. Will update here if they continue to insist on having the data displayed in the older format.
Thanks!

Hi @Sanskrity. The customer had the below update :
SQL query takes around 2 mins run whereas earlier it used to barely take a 15-30 seconds. This is happening due to change in the format. Customer is willing to go on a call and explain as to why this is important for them. Let us know how we can take this forward.

Hi @shahnawazsur - The timestamp formatting shouldn’t affect our SQL latency. If this is happening in their system, please ask the customer to place a check first to format the timestamp according to their database convention and then query. That should solve for it.

1 Like

Hi @Sanskrity
Thanks for the update.
Customer says that the convert itself is taking time… not the query afterwards.

@shahnawazsur I understand but since this is not an absolute blocker, we won’t be changing the format back in order to keep it readable across platform.

Okay. They don’t want to change it but rather add one more column where the old timestamp will be displayed.

@shahnawazsur No, we won’t be adding another timestamp field to a default dataset.

Okay. Understood. Thanks a lot for your help @Sanskrity