Detect time-traveling phones offline

[ecsalomon]

Is your feature request related to a problem? Please describe. Because phones are sometimes offline for extended periods, their internal clocks can become out of sync with the correct time. This causes a number of problems:

• Decision support based on calculated age may be made incorrectly: for example, the number of breaths qualifying as fast breathing differs based on patient age; if the wrong age is used, an incorrect triage decision may be made
• Task schedules become interrupted: for example, if a pregnancy registration happened before a clock became out of sync, the ANC visit tasks associated with that pregnancy may not be prompted at all or may be prompted at the wrong clinical time, depending on the type/severity of time drift
• Analytics become inaccurate/problematic: When task report times are inaccurate, we cannot calculate basic metrics like the time between visits, and these problems are compounded for more complicated metrics and data science applications

Describe the solution you'd like We can probably use some basic diagnostics upon starting the application to detect internal clock "time travel" and prompt the user to turn on data long enough to update the clock or manually update the clock.

To detect phones traveling backwards in time, we could check:

• Is the current time < most recent sync time?
• Is the current time < most recent report time?

Detecting phones traveling forward in time seems a bit harder, but we could try some things like:

• Is the current time more than 30 days greater than the time of last report?

Describe alternatives you've considered None, but am open to any!

Additional context

[garethbowen]

@ecsalomon We have some code in the app which, if the user is online, compares the local time with the server time. Assuming this is working correctly it then prompts the user to fix the time on their phone but it's likely that the users are ignoring this dialogue. The delta their time and the server time is also now recorded in user telemetry so it's possible to find users who have the time set incorrectly. You can try this out by setting your clock incorrectly then logging in to the app.

[ecsalomon]

@garethbowen I'm proposing we check while offline to prevent the accumulation of incorrect care and bad data before syncing.

I'll try to check on the telemetry data this week to see if I can pull together a quick analysis of how persistent/'sticky" the problem is for individual CHVs as a proxy for ignoring the message.

We could probably improve the message a bit. The current message is:

Missing targets is good to mention, but I think "corrupt data" is a bit abstract. What about something like this, that leads with the risks most relevant to the CHW:

[kennsippell]

@ecsalomon If you're looking for the telemetry event client-date-offset was added in 3.7.0.

[ecsalomon]

Based on an analysis of data from two projects @sacul-git asked a very good question:

Question: the (very rough) general trend in the plots for both projects suggest that time drift is more prevalent near the beginning of the timeline. Would this be because these are newly set-up phones and CHWs simply haven't had the opportunity to notice the time is off? In that case, would there be a way of including a step in the setup instructions (if there is such a document) to prompt whoever is setting up the app to make sure the phone clock is correct?