Loop does not provide a propper UTC offset to nightscout

[haspden]

Describe the bug
Loop does not provide any UTC offset value (or provides a UTC offset as 0) to the nightscout.
This is challenging for any application which uses nightscout to view from the uploaders perspective, and not the viewers perspective.

Attach an Issue Report
Tap the Loop settings icon on the bottom of the screen, then tap Issue Report and attach it to this ticket.

To Reproduce
Steps to reproduce the behavior:

1. Upload any data to Nightscout via Loop
2. View api output data /api/v1/entries.json/sgv
3. Check UTCoffset value

Expected behaviorxq
A utcoffset value to represent the uploaders UTCoffset in minutes
"utcOffset": 120, where user is at UCT + 2hrs
"utcOffset": -60, where user at UCT - 1hrs

Screenshots

  {
    "_id": "6808d23bb781a985a30be5e2",
    "isCalibration": false,
    "type": "sgv",
    "device": "Dexcom G7 DXCM3T",
    "dateString": "2025-04-23T11:42:43.000Z",
    "direction": "FortyFiveUp",
    "sgv": 137,
    "date": 1745408563081.73,
    "trendRate": 1.1,
    "trend": 3,
    "utcOffset": 0,
    "sysTime": "2025-04-23T11:42:43.000Z",
    "mills": 1745408563000
  },

[haspden]

Whilst internally Loop works at UTC globally, when uploaded to 3rd parties (like nightscout) it should not be applying a utcoffset of 0 as this indicates the event occurred at a UTC timezone.

[marionbarker]

Nightscout knows how to handle UTC. The profile determines how it displays the UTC data. The offset of 0 just means the timestamp is in UTC.

What are you trying to accomplish here?

[haspden]

Hi @marionbarker , thanks for yuour response. I believe the Z in a timestamp denotes a UTC relative timestamp, the offset denotes the offset at which it was uploaded from.

For example if I am in UTC +1 I would upload a 14:00 localtime glucose value as 13:00:00Z with a UTC offset of 60. (This is not the same as 13:00:00Z UTCoffset 0) yet both store utc timestamps

The use of UTCoffset allows us to know the timezone the user was in when the data was uploaded.

We're overlaying Nightscout data with other sources, but want to display the time from the user's timezone perspective to other viewers, not the viewer's perspective.

Imagine a nightscout report for a person in the UK (UCT +1) being viewed by somebody in New York UTC -4. I would not want the clinician in New York to think a hypo occurred at the user's 09:00 loally, or 13:00 utc, when it actually occurred at 14:00 relative to the user.

The only way to achieve this is with the proper use of UTC offsets, however many of the Nightscout uploaders are either omitting these or falsely uploading utcoffset = 0.

For a pure nightscout user this isn't a huge issue, as nightscout performs front end timezone tranformation to the viewers local time, as it assumes the viewer is always in the same timezone at the uploader, however often a travelling parent, clinician etc may not always be in the same timezone and so it makes viewing the data from alternative timezones not possible when these are not entered.

Some Examples of platforms which seem to do this correctly

• AndroidAPS
• Guardian Monitor

[janvv]

@haspden Thank you for bringing this up. I did raise this topic before but never made much progress. I also find timezone management and persistence in nightscout and loop rather confusing. Time and timezone management is one of the most challenging engineering tasks.

If you don't manage time, time manages you

First of all, i am missing a good documentation about what the different fields refer to:

In the entries table: date, dateString, sysTime, utcOffset.
date: probably supposed to be always the local time (utc) as epoch timestamp
utcOffset the numerical offset from local time (in minutes?)
dateString: the timezone aware datetime string

In the treatments table:
timestamp: a timezone aware iso date String
utcOffset: numerical timezone offset from local time (in minutes?)

First of all: It can make sense to have date and utc offset be stored numerically and having a datestring to improve query speeds.

Challanges:

1. Inconsistencies: In entries we have 4 fields, in treatments only 2
2. Naming: in entries the datetime string is called dateString, in treatments it is called timestamp. Note: The name timestamps traditionally represents the UNIX epoch time in seconds (since 1970)
3. Redundancy: Given that dateString is a timezone aware string, having an extra utcOffset is redundant (Yes, query speed but we don't have this in other tables either).
4. Ambiguity: A utcOffset of 0 or a Z at the end of the datetime string Z implies that the user's location is at UTC+0.

My assumption that the date strings are supposed to be timezone aware might be wrong: To my understanding, mongodb does not support storing and filtering timezone aware objects (it treats them as utc, ignoring the tzinfo to my understanding). So it could be that dateString and timestamp are intended to be always UTC. Quite confusing to be honest because the timezone info implies there could be others. In this case, utcOffset would of course not be stored redundantly. Docs would really help here.

Loop: Seems to never provide the timezone offset. In my case, i am at UTC+2 and Loop also only provides utcOffsets of 0. Meaning that when i travel and don't have exact records of my travel time and destinations, i won't be able to recover local times.

One more thing: Loop also does not seem to create profiles in nightscout that would allow tracing the users timezone. At least for me, the profile table has no timezone information and nightscout does not display it either.

My assumption is that this often gets unnoticed because Loop+nightscout display mostly correct times when the user is in viewing the data in the right timezone. However, when creating reports, analyzing and reviewing historic data (from your travels, daylight saving time change etc...) the time information is probably wrong. Or did i miss something?

I don't even want to think about the implications of stuff like auto-tune while traveling cross continent.

TLDR: I vote for better documentation, streamlining datetime fields and names and correct use and persistence of actual user timezone information

[haspden]

A helpful user of our Nightscout integration just provided a fix for Nightscout Kit

"There are actually two issues. The first is within the Loop code itself. These are the changes he’s made if it’s of use to you to see or share: DrFlibble/NightscoutKit@main...timezone-fix

But in order for them to work, the CGM data in NS needs to come from Loop itself, because NS is also not setting timezones correctly fir data direct from Dexcom Share (via either the deprecated Bridge or newer Connect). For Loop users this involves turning on the “upload readings” setting in the CGM menu in Loop."

Hopefully this can be merged into the main branch as it is correctly saving timezones now of this user, and they're appearing via the NS api with a non 0 value on the UCToffset