Fix Glooko timezone handling across DST - #58
Open
lukas-slansky wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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/PragueCalculates the applicable UTC offset separately for each timestamp, including historical data across DST boundaries.
Keeps
CONNECT_GLOOKO_TIMEZONE_OFFSETas a backward-compatible fixed-offset fallback.Gives
CONNECT_GLOOKO_TIMEZONEprecedence when both settings are configured.Applies the timezone conversion to:
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
Zsuffix. For example, a reading displayed by Glooko as20:53 CESTis returned as2026-08-16T20:53:50.000Z, requiring timezone context to convert it to the correct UTC instant (18:53:50Z).The Glooko
/api/v3/session/usersresponse contains atimezoneproperty, but it isnullfor bothcurrentUserandcurrentPatienton the tested account, so the timezone cannot currently be reliably derived from Glooko itself.Testing
Added regression coverage for:
timestampandxvaluesThe full test suite passes.
The change was also tested against a real Glooko EU integration using
Europe/Praguewhile deliberately configuring the legacy fixed offset as1. 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.