Repository navigation
fix: synced() stays true once the network has set the clock (release 0.10.2) - #59
Merged
Merged
Conversation
time.synced() and datetime.synced() compared ezTime's status with timeSet. ezTime drops to timeNeedsSync when an NTP refresh is overdue (~90 min), so on a network that blocks NTP — where Courier sets the clock from the HTTP Date header — an app saw the clock turn unsynced an hour and a half after boot while it ran on. Both now share clockSynced(): set at least once (timeStatus() != timeNotSet), from either source. The test stub's ezTime gains `stale` (timeNeedsSync); a test in each module checks a stale clock is still synced, and both fail on the old check. prompts/sandbox.md: "until the network sets the clock", not "until NTP". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
genmon
changed the title
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.
time.synced()anddatetime.synced()compared ezTime's status withtimeSet.The bug: ezTime drops to
timeNeedsSyncwhen an NTP refresh is overdue (about 90 minutes). On a network that blocks NTP, Courier sets the clock from the HTTP Date header, so about 90 minutes after boot an app saw the clock turn unsynced while it was running fine.The fix: both calls now share
clockSynced(), which means the clock has been set at least once (timeStatus() != timeNotSet), from either source. "Synced" means the network has set the clock; which way it did doesn't matter. The same fix is in Courier: inanimate-tech/courier#38.Tests: the test stub's ezTime gains a
stalestate (timeNeedsSync). A new test in each module checks that a stale clock is still synced, and both fail on the old check. Unit tests pass 271/271, and static analysis is clean.Also:
prompts/sandbox.mdnow says "until the network sets the clock" instead of "until NTP". arc's verbatim copy of that sheet follows when it next pins Resident.Changelog:
v0.10.2-dev.🤖 Generated with Claude Code