Time and Clock Sync

Time and Clock Sync

TOTP codes are computed from the current UTC time, and must be right to within roughly ±30 seconds or every code is rejected. On classic Amigas this is the real engineering problem:

• Many machines have no battery-backed clock (stock A500/A600/A1200) and boot to the wrong date entirely.
• Machines that do have an RTC conventionally keep local wall-clock time, not UTC — so even a perfectly set clock is hours off UTC.
• AmigaOS has no reliable native timezone concept before 3.2, and only a partial one after.

AmiAuth solves this with a layered model that degrades gracefully from a networked machine down to a floppy-booted A500 — and it never touches your system clock; it computes a correction and uses corrected time internally.

The layers

Highest-confidence source wins. Each maps to a trust colour, shown as the LED in the GUI and reported by the CLI CLOCK command:

Priority	Source	Colour	Meaning
1	SNTP sync over the network	🟢 Green	Offset measured against an internet time server — trustworthy
2	Locale timezone (locale.library)	🟠 Amber	A sensible first guess from your Locale prefs — unverified
3	Explicit UTC offset you set	🟠 Amber	Trusted as much as you trust your own clock
4	Manual nudge (± seconds, by eye)	🟠 Amber	Hand-tuned
5	Nothing	🔴 Red	Codes are being generated from an unverified clock — they may be wrong

Green means codes should be accepted first try. Amber means AmiAuth is applying a correction it cannot verify — usually fine, but watch out for DST (below). Red means nothing has confirmed or corrected the clock at all.

SNTP sync (green)

If a TCP/IP stack is running (bsdsocket.library present — AmiTCP, Roadshow, Miami, an emulator's bsdsocket, …), AmiAuth can measure your clock's offset with a single small UDP exchange against an NTP server. Zero configuration.

• CLI: run SYNC (see CLI Reference). The measured offset and the server are saved to ENVARC:AmiAuth/, so subsequent GET/CODE calls — and the GUI — use the corrected time even after the stack goes down.
• The sync does not set your system clock; it only records the offset.
• Green means freshly verified. The green state applies to the run in which the sync happened; a stored offset loaded on a later run (or by the GUI) is honestly reported as amber, because AmiAuth can no longer vouch for it — your clock may have drifted since. The corrected time is still applied either way; re-run SYNC to re-verify. The GUI does not perform SNTP itself — sync from the CLI.

If you have no network, the amber layers below cover you.

Locale timezone (amber, automatic)

If you have set your timezone in the Locale (or TimeZone) Prefs, AmiAuth uses that offset as an automatic first guess — an offline machine with correct local time and a configured locale "just works" with no setup.

Two caveats, which is why this is amber, not green:

• No automatic daylight-saving. The classic locale offset is fixed year-round, so it can be an hour wrong in summer — far outside TOTP's tolerance. If your codes stop working when the clocks change, this is why: run SYNC, or set an explicit offset.
• It assumes your Amiga clock holds local time (the convention). If you deliberately keep your clock on UTC, set an explicit offset of 0 instead.

Explicit offset and manual nudge (amber)

With no network and no locale setting, tell AmiAuth the offset yourself with the CLI OFFSET command (see CLI Reference), or nudge the correction by ±seconds while watching the countdown. The offset persists in ENVARC:AmiAuth/ across reboots.

Checking the current state

• CLI: AmiAuth CLOCK reports the corrected time, the active source and the trust state.
• GUI: the LED shows green/amber/red at all times — see the GUI Guide.

Practical advice

Your setup	What to do
Networked machine or emulator	Nothing — run SYNC once (or let the GUI sync); re-run after big clock changes
Offline, RTC on local time, Locale configured	Nothing — amber locale guess applies automatically; mind DST changes
Offline, no RTC (clock wrong at boot)	Set the clock at boot (even roughly by hand), then OFFSET/nudge until codes work
Clock kept on UTC	Set an explicit offset of 0

A wrong code at a website is almost always a time problem, not a secret problem — check CLOCK first. See Troubleshooting and FAQ.