Skip to content

Fix Glooko timezone handling across DST - #58

Open
lukas-slansky wants to merge 1 commit into
nightscout:mainfrom
lukas-slansky:fix/glooko-timezone-dst
Open

Fix Glooko timezone handling across DST#58
lukas-slansky wants to merge 1 commit into
nightscout:mainfrom
lukas-slansky:fix/glooko-timezone-dst

Conversation

@lukas-slansky

Copy link
Copy Markdown

Summary

Adds support for DST-aware Glooko timestamp conversion using an IANA timezone, while preserving the existing fixed-offset configuration for backward compatibility.

Fixes #10.

Changes

  • Adds CONNECT_GLOOKO_TIMEZONE, for example:

    • CONNECT_GLOOKO_TIMEZONE=Europe/Prague
  • Calculates the applicable UTC offset separately for each timestamp, including historical data across DST boundaries.

  • Keeps CONNECT_GLOOKO_TIMEZONE_OFFSET as a backward-compatible fixed-offset fallback.

  • Gives CONNECT_GLOOKO_TIMEZONE precedence when both settings are configured.

  • Applies the timezone conversion to:

    • v2 CGM readings
    • v3 graph CGM readings
    • currently fetched pump bolus and scheduled basal treatments
  • Validates configured IANA timezone names.

  • Does not change the Glooko graph query time range.

Background

For the Glooko EU account used for testing, v3 graph timestamps behave as local wall-clock values encoded with a Z suffix. For example, a reading displayed by Glooko as 20:53 CEST is returned as 2026-08-16T20:53:50.000Z, requiring timezone context to convert it to the correct UTC instant (18:53:50Z).

The Glooko /api/v3/session/users response contains a timezone property, but it is null for both currentUser and currentPatient on the tested account, so the timezone cannot currently be reliably derived from Glooko itself.

Testing

Added regression coverage for:

  • winter and summer timestamps in the same batch
  • DST transition boundaries
  • v3 graph timestamp and x values
  • invalid IANA timezone validation
  • IANA timezone precedence over the legacy fixed offset
  • pump bolus and scheduled basal treatments
  • preservation of existing fixed-offset behavior

The full test suite passes.

The change was also tested against a real Glooko EU integration using Europe/Prague while deliberately configuring the legacy fixed offset as 1. During CEST, entries were correctly converted using the 2-hour DST offset, confirming that the IANA timezone path was being used.

The behavior of Glooko timestamps during the repeated hour at the autumn DST transition has not yet been verified against real data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Timezone offset for glooko does not respect daylight savings time (DST)

1 participant