My date fields are downloaded with a -1days on the value.
I am using ODK Suitcase to download my data from ODK Aggregate Server. I have noted that the date fields values subtract 1day on the record. For example a date like April, 30 come out as April, 29.
In the tablet in ODK Survey the value is correct. Even if I upload the data in the tablet the date comes out correct.
Could it be because of the time zone difference? There is a 7 hours difference between the server time and where the survey is being conducted. If this is the cause, how can I make it record the actual value entered by the user.
I would appreciate any help!!
You should be able to test whether the time zone is the issue if you can time a few dates and download so that some would clearly be the same and others different if the issue is the time zone.
One solution would be to assign a string equal to the date within the survey, right after the date is entered. The string should not change depending on the time zone.
@cmuchuchuti you are correct it’s a timezone issue. The system always stores dates in the UTC timezone for consistency.
Most programs know how to adjust the date from UTC time to “local time” so you might want to check out if you can do that with your data flow.
One example of storing everything in UTC does not make sense is recording someone’s date of birth (DOB). Generally, DOB is not timezone adjusted so we decided to create a new date “type” that does NOT do timezone adjustments. @Jeff_Beorse has created a pull request with the changes that is under review to add a no date with no timezone adjustment. Here is the pull request to track the change’s progress: https://github.com/odk-x/app-designer/pull/136
Unfortunately I am not sure @elmps2018 solution of assigning a value would work because the value is still represented in UTC, the computer UI is automatically adjusting it to the timezone. The database value will still be UTC and it depends on the UI to render. You could just have the user enter the value with “type” string instead of type date. I would recommend though there are so many tools to timezone adjust you can probably convert what you want and look for the next release which should fix this problem and use the no timezone adjustment type.
1 Like
Thank you @W_Brunette and @elmps2018 for the responses. Will keep following the pull request to see the developments.
@elmps2018 I will try and implement that. It looks like it may be a reasonable workaround given that there is no solution currently. @W_Brunette I think what @elmps2018 is saying may work. It will be a matter of assigning the date value entered to the created text variable. And as such my guess would be since the variable would be treated as text, it will not be affected by the time difference. I will test it and advise.
2 Likes