[BACK-3030] Persist latest time zone offset for Dexcom Connection into data set #726
Conversation
…o data set - Determine time zone offset for Dexcom Connection from most recent datum - Persist time zone offset for Dexcom Connection in data set - Use display time zone offset, if available, in time zone calculation - https://tidepool.atlassian.net/browse/BACK-3030
- Fix Dexcom time handling with and without time zone specifier - Updates based upon PR review
|
This adds considerably more work in order to parse Dexcom date/time strings correctly and, more importantly, to capture whether the original date/time string included a time zone specifier or not. While the attempt to parse the date/time string is a tad over-lenient, given what I've seen with real production Dexcom data, hopefully this will prevent any date/time parsing issues (and parse them as correctly as possible). If the time zone was specified on the display time, then the time zone offset is forced to that with an appropriate change to the conversion offset (so the UTC bootstrapping calculations remain correct). This gives us the best change of have the time zone offset correctly represent |
|
@toddkazakov @jh-bate Just need a quick approval after I merged in Todd's alternate implementation of time parsing. |
Note: I attempted to add tests for the key piece of this change, but ran into challenges. First, there are currently no tests at all for this code (ultimately, my bad). Second, I now have a whole set of tests that incorporate this change, as well as significant other changes (for related Dexcom work), but changing those tests to allow them to work just for this one change (without the rest) would be a significant lift and effectively throw-away (since it would be soon replaced by the new tests).