mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-29 01:38:37 -04:00
Isaac ConnorandClaude Opus 5
0e19f4fb4c
Both cameras found on this network kept accurate UTC with no timezone set, so their clocks were five hours out on the overlay while the recordings themselves were correctly stamped. The factory daylight saving rule was also nonsense everywhere: thirty minutes, March to September. set_time points the camera at an ntp server and sets its timezone, with optional summer time rules. The timezone is derived from a UTC offset rather than hardcoded: the vendor's list starts at GMT-12:00 and steps every thirty minutes, so -6 becomes index 12, which its own language pack labels "(GMT-06:00) Central Time (US&Canada)". An offset with no index, a quarter hour zone say, is refused instead of silently rounded. These settings live in flash and set_time is meant to be safe to re-run, so nothing is written unless it differs. Verified against a camera: an unchanged call issues no write at all, a changed server issues exactly one, and restoring it issues one more. The comparison recurses into the nested start and end rules, which would otherwise always differ as hash references, and compares as strings because the camera returns numbers and JSON booleans interchangeably. dstType is deliberately not sent. Supplying week based rules makes the camera set it itself, and it rewrote the value we sent, so sending one would mean a read back that never matches what was written. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvTCzCbvGt8xKQRNCSA7o8