Client-based timestamps ("shown"/"answered") are one hour wrong (too early)

[Ludwig Ohse]

Dear formr-team,

the client-based timestamps ("shown"/"answered") in my data are one hour wrong (too early).

I tried it with different browsers and devices, but it is mostly wrong. I also inspected my survey/run-data generated by others and it was the same pattern. Interestingly, timestamps for "block"-items were mostly correct. Is this a bug?

Could this be the reason why the inactivity expiration doesn't work (for me)?: https://groups.google.com/forum/#!topic/formr/QTf35PJkdXA

You can find two screenshots below.

Best,

Ludwig

[Ludwig Ohse]

Dear formr-team,

there is more evidence that there might be something wrong with the timestamp-system (at least for me).

I want to implement a JS in formr which tracks whether participants leave the page (defocusing-event) and come back to the page (refocusing-event): https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/formr/FYeb2yearh8

The defocusing- and refocusing-events are marked by timestamps. When I test my JS in formr, it (often but not always) produces two defocusing events when I leave the page one time (while it should produce only one defocusing event). When I test the same JS in jsfiddle, it works as expected (one defocusing event for leaving the page one time).

This timestamp-issue is really problematic for me, because I need to use the JS. In addition, I want to collect reaction times which seems not possible with the issues I described.

I hope there is a solution for this

Best,

Ludwig

[Ruben Arslan]

Hi Ludwig,

I wouldn't try to build a way to measure RTs in formr from scratch, unless you want

to spend a few months learning about frame rates, browser detection etc. 

Use a validated solution like lab.js or psychopy js. lab.js that can be integrated with formr

and use formr as the data's backend.

The 'one hour' off finding for timestamps may be related to timezones; the formr server

is set to Europe/Berlin, maybe your testing machine isn't. Did you look

at the timezone part? Do you need absolute timestamps for anything? The relative ones are more precise.

Regarding the defocusing event: it's hard to say anything without a reproducible example (actually true

for the timezone problem too). Please get in the habit of providing them :-)

Best,

Ruben

--
You received this message because you are subscribed to the Google Groups "formr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to formr+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/formr/faed0e94-60ae-4259-942c-161a15af122e%40googlegroups.com.

[Ludwig Ohse]

Hi Ruben,

thank you for the suggestions to use lab.js or psychopy js. to capture RTs.

I also assumed that there might be a problem with the timezones. But what do you mean by changing the timezone of the "testing machine"? Can I change the timezone within formr? The timezone of the operating systems of my devices are UTC+01:00 (Berlin etc.). The time on my PC matches the server-based timestamps, i. e. the "created"/"saved"-columns of the results in formr. You can find a reproducible example attached (note: the "block"-item in my example was shown while testing, but there is NA in the "shown"-column). I think I don't need the absolute timestamps, but aren't the relative timestamps based on the absolute ones?

I tested the PageFocus-JS in a run which creates live feedback on the defocusing/refocusing-events: https://page-focus-test.formr.org/

This was very informative, because it shows that in some browsers (Google Chrome, Mozilla, Samsung Internet Browser) clicking on a radio button is counted as a refocusing event and clicking on the regular website-surface afterwars is then counted as a defocusing event. This, however, does not happen in Internet Explorer and Safari. I guess this is an JS-issue and not a formr-issue, right? In addition, in Mozilla every defocusing event is counted twice. This would be acceptable for my purposes - the other issue of course not.

Thanks a lot! :)

Best, Ludwig

To unsubscribe from this group and stop receiving emails from it, send an email to fo...@googlegroups.com.

[Ruben Arslan]

Hi!

 

I also assumed that there might be a problem with the timezones. But what do you mean by changing the timezone of the "testing machine"? Can I change the timezone within formr? The timezone of the operating systems of my devices are UTC+01:00 (Berlin etc.). The time on my PC matches the server-based timestamps, i. e. the "created"/"saved"-columns of the results in formr. You can find a reproducible example attached (note: the "block"-item in my example was shown while testing, but there is NA in the "shown"-column). I think I don't need the absolute timestamps, but aren't the relative timestamps based on the absolute ones?

Yes I meant your devices. If it isn't that, I don't know :-( 

 

I tested the PageFocus-JS in a run which creates live feedback on the defocusing/refocusing-events: https://page-focus-test.formr.org/

This was very informative, because it shows that in some browsers (Google Chrome, Mozilla, Samsung Internet Browser) clicking on a radio button is counted as a refocusing event and clicking on the regular website-surface afterwars is then counted as a defocusing event. This, however, does not happen in Internet Explorer and Safari. I guess this is an JS-issue and not a formr-issue, right? In addition, in Mozilla every defocusing event is counted twice. This would be acceptable for my purposes - the other issue of course not.

Yes, this sounds a like a bad script that doesn't work cross-browser. Maybe you can find a better implementation somewhere?

Best,

Ruben

 

To unsubscribe from this group and stop receiving emails from it, send an email to formr+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/formr/e4ff0c6c-ff2c-4746-9536-5952137906ec%40googlegroups.com.