CA SDM Date/Time Edit Problem

[BarisY]

Hello,

 

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?

 

Regards,

Barış

Attachment(s)

net trace.har.zip   1.64 MB 1 version

detail_in.htmpl.zip   11 KB 1 version

[Michael Mueller]

Hi Barış

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 .

Regards

............Michael

[BarisY]

Hello Michael,

 

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.

 

Regards,

Barış

[Michael Mueller]

Hi Barış

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.

A received epoche timestamap is converted to its string representation by the javascript function date_to_string(...).

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.

Regards

............Michael

[BarisY]

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:

\r\n\r\ndetailDateReadonly(\"Çözüm Tarihi\",\"zODYA_ResolvedDate\",1,\"yes\",\"1484140833\")

 

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.

 

Thanks.

Barış

[Michael Mueller]

Hi.

Without looking into the files yet, do you access $args.zODYA_BilCvplamaTrhi in your template somewhere before the corresponding pdm_macro, in a javascript function for example?

Regards

...........Michael

[BarisY]

Hi,

 

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>

 

Regards,

Barış

[Michael Mueller]

Hi Barış

I found the problem:

instead of

<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>

 

do a

<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>

 

For clarification:

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

..............Michael

[BarisY]

Thanks a lot Michael that solved the problem.