Versions:
Pi-hole Core: v6.4.2
Web: v6.5.1
FTL: v6.6.2
Platform: Debian 12 (armv5tel), Pogoplug v4
Browser: LibreWolf (Firefox-based)
Expected behaviour:
Query Log should display timestamps in local time (BST, UTC+1), matching the system clock and browser clock.
Actual behaviour:
Query Log timestamps are consistently displayed exactly 1 hour behind actual local time — appearing to show GMT/UTC rather than BST.
Steps to reproduce / diagnostic steps taken:
Confirmed date on the Pi-hole host shows correct BST time (Europe/London timezone set correctly via dpkg-reconfigure tzdata, confirmed post-reboot).
Confirmed browser JS clock is correct: new Date() in console returns correct BST time with correct GMT+0100 offset.
Queried FTL's pihole-FTL.db directly for the most recent query's raw timestamp column and compared to time.time() in Python — confirmed accurate to within 46 seconds (i.e., FTL is storing the correct UTC epoch).
Checked browser Local Storage for the Pi-hole host — no timezone-related keys present, ruling out client-side caching of an old timezone.
Despite all of the above being correct, the Query Log page consistently displays timestamps exactly 3600 seconds (1 hour) behind the actual current local time.
Conclusion: The discrepancy appears to be isolated to the web UI's timestamp rendering/conversion logic, which seems not to be applying the DST (BST) offset correctly, even though all underlying data (FTL epoch) and environment signals (OS clock, browser clock) are accurate.
Screenshot taken at 07:35 BST — log shows the latest entry at 06:20, exactly 1 hour behind actual local time.
Versions:
Pi-hole Core: v6.4.2
Web: v6.5.1
FTL: v6.6.2
Platform: Debian 12 (armv5tel), Pogoplug v4
Browser: LibreWolf (Firefox-based)
Expected behaviour:
Query Log should display timestamps in local time (BST, UTC+1), matching the system clock and browser clock.
Actual behaviour:
Query Log timestamps are consistently displayed exactly 1 hour behind actual local time — appearing to show GMT/UTC rather than BST.
Steps to reproduce / diagnostic steps taken:
Confirmed date on the Pi-hole host shows correct BST time (Europe/London timezone set correctly via dpkg-reconfigure tzdata, confirmed post-reboot).
Confirmed browser JS clock is correct: new Date() in console returns correct BST time with correct GMT+0100 offset.
Queried FTL's pihole-FTL.db directly for the most recent query's raw timestamp column and compared to time.time() in Python — confirmed accurate to within 46 seconds (i.e., FTL is storing the correct UTC epoch).
Checked browser Local Storage for the Pi-hole host — no timezone-related keys present, ruling out client-side caching of an old timezone.
Despite all of the above being correct, the Query Log page consistently displays timestamps exactly 3600 seconds (1 hour) behind the actual current local time.
Conclusion: The discrepancy appears to be isolated to the web UI's timestamp rendering/conversion logic, which seems not to be applying the DST (BST) offset correctly, even though all underlying data (FTL epoch) and environment signals (OS clock, browser clock) are accurate.
Screenshot taken at 07:35 BST — log shows the latest entry at 06:20, exactly 1 hour behind actual local time.