ARO (7.5.2016.46) date and time displayed in UTC when mapped to a text
Jacky_Gross
Customer Adept IT Monkey ✭✭
Hello,
When creating a Service Request on portal (8.6.0.2016) and selecting a date value mapped to a text field (description), the date put into the text field is UTC instead of current server which is UTC+2. In the controls and user input data is correct.
The issue appeared after the upgrade to 8.6.0.2016 - before the upgrade everything worked just fine. Created an incident for that but maybe someone already encountered this situation.
Best regards
When creating a Service Request on portal (8.6.0.2016) and selecting a date value mapped to a text field (description), the date put into the text field is UTC instead of current server which is UTC+2. In the controls and user input data is correct.
The issue appeared after the upgrade to 8.6.0.2016 - before the upgrade everything worked just fine. Created an incident for that but maybe someone already encountered this situation.
Best regards
0
Best Answer
-
Brian_Wiest
Customer Super IT Monkey ✭✭✭✭✭
I ran into this on installing v8.4.3
An updated was made to accommodate how date/time fields get mapped into the work item. Basically so that everything gets localized from the portal into the database correctly.
For instance before v8.4.3 if you mapped your start date to scheduled start date the time would be written into the database as the users localized time not UTC which the DB uses. So any view that localized the value in the console or portal the value would be off.
Then when v8.4.3 was released Cireson fixed that, the offset is that when mapping the value into a plain txt field it is written in the UTC format which the DB uses.
I think they are working on a control that would determine the save set format and convert based on use case.
In the mean time it is one or the other.
For my environment we use the txt fields more that anything else so support provided my an update to change it back. Each time you install you have to modify this.In CiresonPortal\Scripts\app\app.controls.js around like 394 make this change:var saveValue = function (val) {targetEle.parents(".form-group").removeClass("has-error");if (settings.targetValId) {if (!val) {$('#' + settings.targetValId).val("");} else {settings.hasTimePicker? $('#' + settings.targetValId).val(kendo.toString(val, "g")): $('#' + settings.targetValId).val(kendo.toString(val, "d"));}HTH7
Answers
An updated was made to accommodate how date/time fields get mapped into the work item. Basically so that everything gets localized from the portal into the database correctly.
For instance before v8.4.3 if you mapped your start date to scheduled start date the time would be written into the database as the users localized time not UTC which the DB uses. So any view that localized the value in the console or portal the value would be off.
Then when v8.4.3 was released Cireson fixed that, the offset is that when mapping the value into a plain txt field it is written in the UTC format which the DB uses.
I think they are working on a control that would determine the save set format and convert based on use case.
In the mean time it is one or the other.
For my environment we use the txt fields more that anything else so support provided my an update to change it back. Each time you install you have to modify this.
Thank you so much for your help and the details about the changes. Everything works fine now.
Best regards
This issue is now solved in v8.6.2 of the portal.
Date values are stored in UTC to any property that has a date data type, and stored in local time in properties with String data types.
No need for custom code.