Epoch syncronization - servers should report UTC time to devices

[snakehand]

Synchronizing time on cellular phones can be tricky. Possible reasons, phone not tracking NITZ, Miss-configured NITZ network or timezone, or daylight saving time. Cross border roaming etc etc. I have suggested that (modified) Julian day numbers should be used as a timescale, since this is sufficiently course, and searching matches +/1 day is not cost prohibitive. But for Design 2 a more fine grained epoch might be desirable. Here I suggest that UNIX time UTC be used, divided down by some suitable interval such as 3600 seconds. By agreeing on UTC time, time zones and daylight saving time are not a introduced, however UTC time can still be difficult to establish.

For this reason I suggest that the server protocol includes a UTC timestamp, that can be used to establish an offset between device time and UTC. No fancy NTP protocol should required as accuracy +/- 10 seconds should be acceptable. This offset is then applied to all reading of system time until a new offset is established.

[dirkx]

It may be useful to note that a normal HTTP response (e.g. from an Apache web server) contains a gratuit Date: line.

So this can practically be as simple as configuring the server to be well behaved and in UTC - and let the app pick out that header (which can be somewhat trusted once a SSL wrapping and, if needed, the usual hard Certiciate pinning to the CA chain is done at ssl level).

[gardners]

Or would it be simpler to just use uncorrected GPS time, since that is easily receivable in the field in most conditions?

…

On Sun, 12 Apr 2020 at 03:41, Dirk-Willem van Gulik < ***@***.***> wrote: It may be useful to note that a normal HTTP response (e.g. from an Apache web server) contains a gratuit Date: line. So this can practically be as simple as configuring the server to be well behaved and in UTC - and let the app pick out that header (which can be somewhat trusted once a SSL wrapping and, if needed, the usual hard Certiciate pinning to the CA chain is done at ssl level). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFCOTZQECH635B2XYCK55DRMCXE7ANCNFSM4MGCZBTQ> .

[dirkx]

@gardners not always commonly available on consumer phones. While that header is - and in this scheme you need to contact that server at least once a day anayway to get the list of infected people.

[gardners]

Understood. My point is really that GPS time can be the most widely available time base, since it is available away from the internet. If the HTTP header line includes the GPS time, that is. This is probably not an unreasonable or difficult burden to achieve.

[dirkx]

Thanks good - suggestion -- added it to https://github.com/dirkx/DP-3T-Documents/blob/implementation-profile-start/meta-arch/meta-arch.md and https://github.com/dirkx/DP-3T-Documents/blob/implementation-profile-start/implementation-profiles/profile.md

[noci2012]

GPS time might help, just don't assume it is available. (GPS might be disabled due to power / privacy / whatever considerations).
The app would need the right for location access anyway so it probably can just start GPS..