Cht-core: Server-side date correction of completed forms

[alxndrsn]

Analytics team reports that forms are TODO insert frequency here received with a clearly-incorrect date attached to them.

_Presumably_ these are submitted from phones with incorrect time/date settings at a system level.

We already detect this in a rudimentary manner in https://github.com/medic/medic-webapp/blob/master/webapp/src/js/services/check-date.js, but perhaps we can add more active measures to:

• detect incorrect date/time settings
• prompt users to fix settings
• correct form submission dates another way, e.g. change reported_date and Nootils.now() function response by calculating delta between system clock and server response's Date headers

[garethbowen]

NB we also store the initial replication date which is generated server side so more likely to be correct. If we detect the reported_date is very wrong we could replace it with the initial replication date.

[alxndrsn]

NB we also store the initial replication date which is generated server side so more likely to be correct. If we detect the reported_date is very wrong we could replace it with the initial replication date.

And this could also be used to calculate a potentially more accurate time using deltas as mentioned above:

correct form submission dates another way, e.g. change reported_date and Nootils.now() function response by calculating delta between system clock and server response's Date headers

[michaelkohn]

Here are a few things I think we can look at to help identify dates that were probably wrong

1. reported date prior to go-live
2. reported date is X months before the initial_replication_date
3. reported date is _after_ initial_replication_date (ie in the future)

For #1: The first tab of this spreadsheet highlights the reported _year_ for 5 big mobile app projects. Pretty much anything earlier than 2016 is going to be a bad date for sure.

For #2 and #3: The second tab calculates (in _days_) the difference between initial_replication_date and reported date on one significant mobile app project. I'm only looking at docs submitted in 2018 and negative numbers mean that the reported date was greater than the initial_replication_date. I chose 60 days as the X from #2.

While the overall % of docs that we _know_ have a bad date is not that high (maybe ~.3%), it is something that happens somewhat regularly.

[ecsalomon]

Looks like there some duplication between this and #6284. I think we can separate the proposed solutions in the two tickets into:

1. Server-side date correction of completed forms, which may be part of a larger workflow management system for data cleaning
2. Improvements to the existing time offset detection/correction and the addition of offline client-side detection

Let's consider this ticket to cover point 1 above and #6284 to cover point 2.