Log the zone each clock-sync stamp was written in - #82
Merged
Conversation
The appliance takes a wall clock with no offset, so the stamp alone cannot show which zone produced it. A container with no TZ set falls back to UTC, writes a panel an hour behind for as long as summer time is in force, and gets 2.04 for it. My own bridge did exactly that, and finding out why took a docker exec into the container rather than a look at the log. The plausibility gate cannot catch it either, since a UTC timestamp is perfectly plausible. zone_name resolves the zone of the stamp rather than the host's current one, so an injected now_fn stays consistent with what gets logged. It falls back to time.tzname where a local zone cannot be resolved, because a log line has no business taking the sync down with it. .env.example carried TZ already and said what it was for. It now says what leaving it unset costs, since the write succeeds either way and nothing about it looks wrong. Claude-Session: https://claude.ai/code/session_01UJBUFo8zZWrebGqf6gUzcL
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
1 participant
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.
ClockSyncTaskwrites a wall clock with no offset, because that is what the appliance takes. The stamp alone therefore cannot show which zone produced it, and a container with noTZset falls back to UTC and writes a panel an hour behind for as long as summer time is in force. The appliance answers2.04either way, and the plausibility gate cannot catch it because a UTC timestamp is perfectly plausible.My own bridge had been doing this since the feature shipped. The oven's panel was an hour behind, and separating "the clock sync wrote the wrong time" from "the appliance is drifting on its own" took a
docker execinto the container, because the log line showed only the stamp:It now carries the zone, which makes the same line answer the question on its own:
zone_nameresolves the zone of the stamp rather than the host's current one, so an injectednow_fnstays consistent with what gets logged, and it falls back totime.tznamewhere a local zone cannot be resolved: a log line has no business taking the sync down with it. The skip warning on the plausibility gate gets the same treatment, since a zone fault is one way to land outside the window..env.examplecarriedTZalready and said what it was for. It now says what leaving it unset costs.No library change, and no change to what goes on the wire. Demo bridge and its tests only.
Tested: deployed to my Unraid bridge and recreated the container, which is what an
env_filechange needs. Both appliances reconnected clean, and the first sync of the session wrote BST to the oven and moved the panel. 761 tests pass,check_share_safety.py --changed-since mainclean.https://claude.ai/code/session_01UJBUFo8zZWrebGqf6gUzcL