Date time formats and export feature request (potential bug)

Datetime display and export: The current export and display rules for timezone are confusing (functionality request), and I am not sure if they are converted correctly (bug). I am comparing activity outside working hours from the para data with the exported time stamps (I converted paradata from UTS to local time) and the results don’t match the way they should.

There might be scope to simplify, by e.g.
a) exporting all timestamps, actions, etc in UTC (to have a clear sequence of file history despite different time zones for tablet and server). Users could convert times they need in local time zone later.
b) in the interface display timestamps that were recorded always in the timezone in which they were recorded in.

Hello Andreas,

if the timestamps don’t match the format description here which was compiled for version 18.06, please provide a specific example and we will fix it.

Keep in mind #5 of the v18.08 release notes.

Best, Sergiy

Hi Sergiy

Many thanks for taking this up. It may be my misunderstanding, please correct me if I am wrong.

An example: I am looking at the date question with current time option InterviewStart for file The interview was recorded in Nigeria (currently 16:44), I am in CET (currently 17:44) and UCT currently is 15:44. Explanations from release note and FAQ are in quotes.

  1. In the interviewer interface I see:
    2018-07-19 10:55:49

(YYYY-MM-DD hh:mm:ss recorded and displayed in the current user’s timezone. Other users will see it adjusted for their timezones.)

I am in CET, an hour ahead of Nigerian time, so this time stamp would have been recorded at 9:55 AM Nigerian time, correct?

  1. In the paradata timestamp I see:
    2018-07-19 08:55:49, the offset variable is missing for the action

… now reflect the local time on the clock of the device where an event was recorded. A new column ‘offset’ was added to reflect the time-zone difference of the device where the event was recorded compared to Greenwich Mean Time (GMT).

This suggest the answer was recorded at 8:55AM local time, which mismatches the local time from the interface in 1. Also note, the some countries using GMT switch to DLS in summer while others don’t. UTC remains constant throughout the year.

  1. In the paradata parameters I see
    2018-07-19 04:55:49

Answer to the date question with the current time option: YYYY-MM-DD hh:mm:ss based on the server or tablet clock (as applicable*) no adjustment for time zone.

The action is from the tablet, so it is tablet time, suggesting the date question was clicked at 4:55 AM . Note that I have not cross checked the tablet time was set correct when this interview was conducted, but most interviewers had it correct, so it is very probable. I am not sure where the difference to 1. or 2. would come from. The offset variable in the para data is filled in for two observations and has the value “-04:00:00”, but and offset of 4hrs is not the difference from local time to UTC, nor to GMT.

  1. In the Stata Data export I see:
    2018-07-19 04:55:49

Timestamp (date question with the current time option): YYYY-MM-DDThh:mm:ss in the device timezone.

This matches the paradata parameters, but not the rest.

Please let me know if you need more details.

To simplify: I would guess that in the interface one would almost always want to see the time when a question was answered. In the export one could either export everything as UTC , or leave the answers to date question with current time in local time and all the rest in UTC (paradata, actions, etc).



Most likely the old events have not been updated. Try the same exercise with interviews collected after Aug 5th. Also, please make sure the tablet time is correct.


Hi Misha

I just double checked for an action conducted today, and it is the same picture.

Interface: 2018-08-06 10:12:17
Paradata timestamp: 2018-08-06T08:12:18
Paradata parameter: 2018-08-06 04:12:17
Export Stata: 2018-08-06T04:12:17



Apologies, forgot to say that the tablet time was correct (based on tablet and server sync time).