xDrip+ should be doing the convertion internally since Linux uses that timezone (well, it uses UTC). I have to admit I haven’t tested xDrip+ across a timezone yet, but I don’t see how an Android app could mess it up.
The Dexcom app and receiver, however, do seem to have this problem as does the Omnipod - swapping time zones at least temporarily interrupts operation of the software.
I have not seen that. What were the symptoms you noticed, @jbowler?
Early versions of the Omnipod UST400 seemed to refuse to do bolus calculations for two hours after a time zone change. That was fixed about the same time as the hardware problem of the backup battery failing was fixed, but all versions still require insulin delivery to be suspended before a time zone change and that means that delayed boluses and temp basals end up being cancelled!
The Omnipod also has the issue I saw with the Dexcom receiver and, indeed, the issue with older Apple and Microsoft operating systems. The Omnipod and, I think, the Dexcom work in local time; I’ve found no way of setting the timezone on the Dexcom (maybe it can be set in the app) and the timezone certainly cannot be set on the Omnipod. This means that a data upload to Dexcom Clarity or Omnipod uploads local time and data overlaps or gaps occur as a result of time zone changes. That’s actually a data loss, which is generally regarded as the most serious of software bugs.
Sorry, I was interrupted so didn’t do my normal review of the second paragraph; the issues with using local time.
In theory the uploader software, which runs on a modern computer, can convert local time from the PDM or CGM into UTC, however this relies on the PDM/CGM (the data logger) having records in the same local time as the computer running the upload software. This should normally be the case but if it isn’t the gaps or overlaps will occur. It also seems that both Dexcom Clarity and Glooko display UTC data in the local time of the computer running the web browser, which would lead to the misleading data I describe below when the original data was logged in a different time zone.
Even if the user (me) remembers the rule of setting the PDM clock to the local time of the computer before an upload there is still an issue of what happens to the stored data in the PDM as a result of a time zone change and I can’t see a practical way of avoiding data loss in this case. This is because the only way of handling the time zone change is to change the time of the existing recorded data; so if you skip forward one hour all the prior data also has to be skipped forward. That means that a bolus you did at 9am yesterday will be uploaded as a bolus at 10am yesterday; the alternative would be a gap of one hour which would be just as bad and more difficult to implement.
The issue is that time of day is very important in analyzing the data; so if I’m getting night time lows and day time highs but I spend a week in Dubai (I live in Oregon, USA) the same pattern is going to be presented as night time highs and day time lows when I get back to Oregon and upload the whole package of data from the trip.
The ONLY way round this is to store UTC+time-zone; zulu time (UTC alone) isn’t enough. Indeed the Omnipod PDM uses time-of-day, which is local by definition, to store basal rate programs so using UTC means changing every basal rate program on a local time change!
I was tempted when I started using the G6 to set the receiver to UTC and I could set the PDM to UTC as well because I use a fixed basal these days, however it was obvious that it didn’t really fix the problem because of the importance of time-of-day to the data.
These days I use xDrip+ for data logging of both the G6 and the insulin delivery; I enter boluses manually but lose the temp basals. xDrip+ automatically changes time zones because the Android phone it runs on does. What I don’t know yet (since I haven’t done a TZ change yet) is whether it stores the time zone information, I suspect not.
OK, now I understand what you mean, @jbowler:
Omnipod: yes—I have found the same problem. To change the time zone you need to change the date/time setting. For that you need to suspend operations. There is no way to track time zone, therefore the Omnipod data won’t keep track of what UTC or local time was when you change the time. It is very messy.
Dexcom receiver: can’t say as we did not use it when changing time zones.
Dexcom app: there is no local time setting. But the operation does not get interrupted by time zone changes. It is not clear to me what happens within and behind the Dexcom app, though. I have always seen continuous data on Clarity: have you seen interruptions or discontinuities corresponding to time zone changes? It is possible that the Dexcom software uses a continuity property to deal with data properly every time. I would be curious to see if you have data that shows the issue actually happening.
Btw, sorry for responding so late—I probably read your post late at night and forgot to reply the next morning…
I’ve now done a full round trip through +16 hours (to Taipei, from SW Oregon) and back. No complaints about xDrip+. The worst problem was caused by AT&T because they don’t correctly update the timezone when I am in the US and, (major bug) Android; while it does update the time from GPS, it doesn’t update the timezone!
The Omnipod was the normal PITA. I always used to use temp basals, but I am doing these almost continuously with the G6 because I set a temp basal to handle protein/fat (gluconeogenesis). The Omnipod forces me to cancel the temp and then doesn’t allow me to reinstate it - I have to enter a new one.
It’s going to be interesting to see what happens with the new Omnipod “Dash” system; supposedly it uses a smartphone (albeit, apparently, one from the dark ages - it isn’t even waterproof) and smartphones, even Offa’s, always handled time zones. [Signature omitted to save two lines.]