Summary
Nightscout reports can display data under the wrong calendar day when the site timezone is set to a non-named timezone (e.g. GMT+4) instead of a standard IANA timezone (e.g. America/Toronto).
This results in report data appearing offset by one day.
Expected behaviour
Nightscout should correctly handle both:
Named IANA timezones (e.g. America/Toronto)
Non-named offset-based timezones (e.g. GMT+4, UTC+2)
Report generation should always align data to the correct calendar day regardless of timezone format.
Actual behaviour
When a non-named timezone (e.g. GMT+4) is set:
Reports become misaligned
Data appears under the wrong day (typically shifted forward by one day)
This persists until the timezone is manually corrected to a named timezone
Real-world example
User located in Toronto (expected timezone: America/Toronto)
Root cause:
External uploader (e.g. Loop) re-uploaded timezone as GMT+4
Nightscout accepted this value but did not correctly handle it in report generation
Steps to reproduce
Set Nightscout site timezone to a non-named value such as:
GMT+4
or
UTC+X
Ensure data exists across multiple days
Open any report view (e.g. Daily / AGP / stats)
Observe:
Data appears under incorrect calendar days
Typically shifted forward or backward depending on offset
Additional context
This can happen when external systems (e.g. Loop or other uploaders) send timezone values as offsets rather than named zones
Nightscout currently accepts these values but does not normalise or interpret them consistently in reporting logic
The issue is intermittent for users because the timezone may switch back and forth depending on uploader behaviour
Suggested fix / direction
One or more of the following:
Normalise timezone input
Convert offset-based timezones (GMT+4) into a proper IANA timezone where possible
Add proper offset handling
Ensure report generation logic correctly interprets offset-based timezones
Validation / warning
Warn or reject non-named timezones in favour of IANA timezones
Fallback behaviour
If a non-named timezone is used, explicitly apply the offset during report calculations
Impact
Incorrect reports
Misleading data interpretation
Loss of trust in reporting accuracy
Workaround
Manually set timezone to a named IANA timezone (e.g. America/Toronto) in Site Settings.
Notes
This issue is not specific to any single uploader (e.g. Loop), but occurs whenever a non-named timezone is used.
Summary
Nightscout reports can display data under the wrong calendar day when the site timezone is set to a non-named timezone (e.g. GMT+4) instead of a standard IANA timezone (e.g. America/Toronto).
This results in report data appearing offset by one day.
Expected behaviour
Nightscout should correctly handle both:
Named IANA timezones (e.g. America/Toronto)
Non-named offset-based timezones (e.g. GMT+4, UTC+2)
Report generation should always align data to the correct calendar day regardless of timezone format.
Actual behaviour
When a non-named timezone (e.g. GMT+4) is set:
Reports become misaligned
Data appears under the wrong day (typically shifted forward by one day)
This persists until the timezone is manually corrected to a named timezone
Real-world example
User located in Toronto (expected timezone: America/Toronto)
Root cause:
External uploader (e.g. Loop) re-uploaded timezone as GMT+4
Nightscout accepted this value but did not correctly handle it in report generation
Steps to reproduce
Set Nightscout site timezone to a non-named value such as:
GMT+4
or
UTC+X
Ensure data exists across multiple days
Open any report view (e.g. Daily / AGP / stats)
Observe:
Data appears under incorrect calendar days
Typically shifted forward or backward depending on offset
Additional context
This can happen when external systems (e.g. Loop or other uploaders) send timezone values as offsets rather than named zones
Nightscout currently accepts these values but does not normalise or interpret them consistently in reporting logic
The issue is intermittent for users because the timezone may switch back and forth depending on uploader behaviour
Suggested fix / direction
One or more of the following:
Normalise timezone input
Convert offset-based timezones (GMT+4) into a proper IANA timezone where possible
Add proper offset handling
Ensure report generation logic correctly interprets offset-based timezones
Validation / warning
Warn or reject non-named timezones in favour of IANA timezones
Fallback behaviour
If a non-named timezone is used, explicitly apply the offset during report calculations
Impact
Incorrect reports
Misleading data interpretation
Loss of trust in reporting accuracy
Workaround
Manually set timezone to a named IANA timezone (e.g. America/Toronto) in Site Settings.
Notes
This issue is not specific to any single uploader (e.g. Loop), but occurs whenever a non-named timezone is used.