I have a custom field for cr object(call_req) table which is intented to be filled by an analyst. That field is shown on the SDM with following line and they can edit it. However, what ever time they choose after they click save button time is saved with minus 1 hour. ex if the user chooses 11/01/2017 02:19 pm it is saved as 11/01/2017 01:19 pm.
<PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi make_required=yes>
I thought this problem is cause by a time zone difference on some field but i couldnt find the rootcause. User desktop, SDM server, SDM database are all at UTC +3.00 Istanbul. I tried the change the field with different users with different roles etc. still same problem. Can you adivse me where can i check next?
That's strange, indeed.
In general: Entered dates in the gui are converted by the browser to an epoche time stamp in UTC timezone and then transferred as these integer values to the sdm server.
Also when receiving date/time information from the server these values are transferred to the browser as epoche timestamps in UTC and then converted to the local timezone and date format.
You may see these values in a http net trace.
Are you sure that the analyst desktop has the correct time settings?
have you checked the database content. Is the date/time correctly saved in the DB. Just do a pdm_extract of the record in question and check if the stored date is correct. pdm_extract will print date/times in the timzone the server is in.
Additionaly I would expect the same behaviour for all editable fields.
What is about other date fields which are editable by the analyst. Do they behave in the same way?
Please confirm .
Thanks for the response. It is really odd for me too. That is the only field which is problamatic and editable by analyst. Now when i check the database i see the field as 1484133540 and it is 11/01/2017 02:19 pm in UTC +3 which is right but the chrome and iexplorer shows this field as 11/01/2017 01:19 pm which is not the case for other fields which are not editable.
Is it possible that browser transforms those fields with different functions.
Thank you for confirmation.
It is good to know, that the value is correctly stored in the DB, so I assume this is "only" a client (browser) problem.
That means, an entered date is correctly converted in the epoche timestamp in UTC and transferred to the server.
The problem seems to be reduced to a display problem only.
And this is used for each and any date field.
Would you be able to attach the source code (as a file), which you get, when displaying the read only detail page and do a ctrl-right click-->View Source to this thread?
Maybe this helps, or at least gives some hints.
Hello again Michael,
As you pointed I realised something from the http net traces.
The faulty field in htmpl file:
<PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi>
The faulty field in net trace:
\r\n\r\n\r\n\r\n\r\ndetailDate(\"Müşteriye Geri Dönüş Tarihi\",\"zODYA_BilCvplamaTrhi\",1,20,\"yes\",\r\n\r\n1,\r\n\r\n\"11/01/2017 01:19 pm\", \"0\")
Custom but normal field on htmpl:
<PDM_MACRO name=dtlDate hdr="Bildirimin Geliş Tarihi" attr=zODYA_open_date>
Normal field on net trace:
I could not figure out why it reachts those fields different. At the original question attachment you can see both htmpl and net trace files.
You can check line 100 for net trace and around 1054 on the htmpl.
Yes, I make a control as follows and when i delete the control it shows as it should be. How can i update the statement so that it wont affect the display method?
<PDM_IF "$args.zODYA_BilCvplamaTrhi" != ""><PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi make_required=yes><PDM_ELSE><PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi></PDM_IF>
I found the problem:
<PDM_IF "$args.zODYA_BilCvplamaTrhi_INT_DATE" != ""><PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi make_required=yes><PDM_ELSE><PDM_MACRO name=dtlDate hdr="Müşteriye Geri Dönüş Tarihi" attr=zODYA_BilCvplamaTrhi></PDM_IF>
If you access a date attribute with $args.date_attr the server substitutes the $args stuff with a string representation of the current date value using the server time zone.
If you want to get the epoche UTC timestamp you nee to specify $args.date_attr_INT_DATE
Unfortunately , this differentiation works only the first time when you access date_attr, all further substititution will take the value of the first substitution regardless if you specify _INT_DATE or not
That said, the first access in the pdm_if in your htmpl was substituted by a string representation. And this was also used in the pdm_macro substitution , which isn't expected by the corresponding js function, and therfor produces a unpredictable result.
Hope this helps
Thanks a lot Michael that solved the problem.