-
Notifications
You must be signed in to change notification settings - Fork 115
Time and the Dexcom
#Dexcom G4's representation of time The Dexcom G4 effectively has 2 times.
- System time is a value that cannot be changed by the user.
- Display time is the user configured time that is displayed on the receiver. The display time is stored internally as an offset to the system time.
Each record has a system time stamp and a display time stamp.
##Challenges The G4 uses the seconds since 2009-01-01 00:00:00 as the epoch. Note the distinct lack of time zone. The value appears be based on where/when the receiver was manufactured. This means the values can be different from receiver to receiver.
This poses a challenge when determining the timestamp of a record. We've identified 2 solutions
###Solution 1 - Use the display time This puts the burden on the user to make sure the time on the receiver display is accurate.
We store the time in MongoDB as the Unix Epoch and as a result the uploader must assume that the timezone set on the uploader matches the timezone represented on the receiver. There are checks that should warn the user if the time difference between the receiver and the uploader is > 20 minutes.
This solution will result in gaps or overlaps of data if the display time is changed (+/- 5 minutes or more) by the user.
###Solution 2 - Use the system time We have to have a trusted external reference since we can't reliably calculate Zulu time from the receiver. Instead, with every receiver download we obtain the time from the trusted source and we also fetch the system time as reported by the receiver. All Android phones today should be able synchronize their clocks with a trusted source and should be accurate (if the user hasn't disabled auto-update) so we decided to use the uploader as the trusted source of time.
Once we've fetched all of the record entries, we then calculate the difference between the current system time of the receiver and the system time of the entry. This should give us roughly how many seconds ago the entry was recorded. From here, it should be easy to calculate the time of a record by subtracting the number of seconds ago since the entry from the current trusted time.
The formula should be:
<Uploader time> - (<Receiver's current system time> - <Record's system time>)
This solution should be resilient to time changes (whether due to travel or day light savings - we make no guarantees for temporal distortions ). It should also avoid any overlap or gaps if the user changes the time on the receiver since the system time cannot be changed by the user.
##Representation of time in uploads There are currently 3 supported methods for uploading
- Direct to MongoDB - uses Solution #1
- REST API - uses Solution #1
- MQTT - uses the download model. Any consumers of this data should refer to solution #2 to calculate the time of each record.