Discord (gadgeteerza, ThinkNode M9, beta_100): no Central Africa zone, the
clock often half an hour behind on a Custom UTC offset, and "Sync clock from
system" with Wi-Fi on not always setting it.
Zones: the saved setting is an index into the zone table, and Custom used to
be "one past the list", so appending zones would have moved it. Custom now
keeps its id (16) forever and the new zones (Central/South/East/West Africa,
Egypt, Eastern/Western Europe, Moscow, Turkey, Arabia, Iran, Gulf, Pakistan,
Nepal, Bangladesh, Indochina, Singapore, Perth, Korea, Adelaide, Brisbane,
New Zealand, Argentina, Mexico City, Newfoundland) sit after it. The picker
shows its own west-to-east order and opens on the current zone.
Half an hour behind: not the offset. WadaNmeaLocationProvider::begin() kept
the parser's pre-rest sentence, so after a GPS saver rest the first loop pass
saw a "valid" fix, the 30-minute re-sync was due, and the clock was set to
the moment the receiver went to rest. begin() now clears the parser, and
UITask::setGpsPower(true) calls syncTime() so the core provider (V4 and
others) gets the same. test_gps_time_sync runs the real provider against a
receiver sending true UTC: the pre-fix provider set the clock 1801 s behind
after a 30-minute rest; now every set is within 1 s.
Sync from system: on the M9 the system clock is the device clock, so the
button copied a clock onto itself. And the Wi-Fi loop wrote only the FIRST
SNTP result into the mesh clock: SNTP's hourly re-syncs set the system clock
only, the PCF8563 kept its old value, and the hourly chip resync (#583)
pulled the clock back to it. Every completed sync is now written through
(SntpClockPush.h, test_sntp_clock_push), and the button with Wi-Fi up
restarts SNTP and says "Clock synced" when the answer lands.
test_time_zones: the legacy ids keep their zones, every zone's offset in
January/July/October, Egypt's DST edges, and all 65536 saved
(tz_zone, time_offs) byte pairs through the exact prefs path to localtime().
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Two ways the clock read hours off while the zone setting looked right.
The ESP32-P4 esp-hosted boards started SNTP with configTime(0, 0, ...),
which also sets TZ to UTC, so from the first Wi-Fi join every displayed
time was UTC until the zone was picked again. #756 fixed this on the
T-Display P4; the CrowPanel P4 10.1 still had it. It now starts SNTP with
the user's zone (configTzTime) and, as on the T-Display, only pushes a
COMPLETED sync into the clock instead of the stale boot time.
Settings > Clock & time fills "By hand (local time)" with the clock's
reading when the page opens. Picking another zone (or stepping the custom
offset) left those digits in the old zone, so "Set clock" right after a
zone change read them in the new zone and moved the clock by the
difference. The field now refills whenever the zone is applied.
The zone table and its POSIX strings move to helpers/TimeZones.h (same
strings, same order) so test/test_time_zones.cpp can check every zone
through the C library's localtime(): January, July and today's offsets,
the US and EU DST edges to the minute, the Custom offset's sign for
UTC-12..+14, and ClockFloorRTC with the zone in force (a later clock set,
like the GPS re-sync every 30 minutes, moves the time and never the zone;
a chip that reads behind the floor or garbage-future falls back to the
system clock).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
