Is the datetime used for Apis related to Conversations, Evaluations, Surveys, Analytics and WFM use datetime or datetime2 for date fields.
I am asking this because we ran into issues related to issue with EmitDateTime in SessionMetrics and SegmentStartDate in SessionSegments of a Conversations. Previously their datatype is datetime and we need to update it to datetime2 to resolve the issues.
Please refer to the API documentation for this information. The data types are documented on every property.
For conversationStart property below is the documentation.
(string) The start time of a conversation. Date time is represented as an ISO-8601 string. For example: yyyy-MM-ddTHH:mm:ss[.mmm]Z.
I want a suggestion like should we use datetime or datetime2?
I don't know what those are without any context. The API provides a string that's in ISO-8601 format as documented. The SDKs handle parsing it for you if you're using the official SDKs and have their own types implemented. But if you're parsing it yourself, you are free to use anything you like that can parse an ISO-8601 timestamp.
In the case of using datetime in EmitDate in Session metrics and Segment StartDate in Session Segments we ran into issues because of milliseconds difference and our pipelines failed. If we use datetime2 instead of datetime our pipelines are not failing.If we use datetime we are running into duplicate records which will fail in the upserts. But when analyzed data from genesys those are not duplicate records and are valid data. If we are using datetime the milliseconds difference is getting trimmed off which inturn make them duplicate records.
I would recommend using a type that doesn't cause you to truncate data and cause failures in your process.
- So are you suggesting datetime2 for all datetime fields in Platform Api?
- Or if it is documented as ISO-8601 should we go ahead with datetime2?
I was asking this specifically because there were lot of changes done for improvement and i want to include them for other parts of the process to avoid these failures in future
This helps me a lot if this is answered
I'm not making any suggestions about how you write your code other than that I suggest you write code that works and adheres to the documented API contracts. If you need assistance determining how to write working code for your use case, hiring Genesys Professional Services for a consulting contract is a good option.
For the old functionality i will leave it as datetime for now unless an issue is triggered and for new functionalities i will go with datetime2.
Thank you @tim.smith for your response
I don't disagree with Tim's answers; use the data type that captures the information to the degree it's expressed and/or you need it, which will vary by programming language and/or database.
In my case I treat EmitDate as a DateTimeOffset to make it easier to recast into other times but I also create a Date version of it to fascilitate reporting by calendar day.
What you do with the data is up to you and your needs.
1 Like
Thank you @Eos_Rios for your suggestions. I was thinking about using Datetimeoffset for Api calls and you made me think on the database side as well.
What is the precision used to save datetime fields in Genesys database.
There is more than one datetime field within Genesys Cloud. Please refer to the API documentation for details about the specific property you're interested in.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.