Files: LifeOS/install/LIFEOS/LIFEOS_StatusLine.sh (USER_TZ resolver) + LifeOS/install/settings.system.json.
Bug
The shipped settings.system.json hardcodes principal.timezone: "America/Los_Angeles", and the statusline's timezone resolver gives settings.principal.timezone the highest priority — above the system clock:
settings.principal.timezone → $TZ → /etc/localtime → /etc/timezone → UTC
Effect
The 5h/7d usage reset timestamp (resets_at, which arrives correctly as UTC from the API) gets formatted in Pacific time on every fresh install. Any user not in America/Los_Angeles sees the reset time off by N hours (e.g. 9h in Europe/Rome), and it never self-corrects when they travel — macOS updates /etc/localtime on timezone change, but the hardcoded setting overrides it.
Root cause
An explicit default TZ is a footgun. A stale/wrong explicit value is just as broken as the UTC fallback the existing code comment already worries about — and worse, it silently wins over the real system clock.
Suggested fix
Ship principal.timezone: "" (empty) by default so the resolver falls through to the OS clock, which self-corrects on travel. Treat an explicit IANA zone as opt-in for headless installs whose system TZ is UTC/wrong — not as the default.
Files:
LifeOS/install/LIFEOS/LIFEOS_StatusLine.sh(USER_TZ resolver) +LifeOS/install/settings.system.json.Bug
The shipped
settings.system.jsonhardcodesprincipal.timezone: "America/Los_Angeles", and the statusline's timezone resolver givessettings.principal.timezonethe highest priority — above the system clock:Effect
The 5h/7d usage reset timestamp (
resets_at, which arrives correctly as UTC from the API) gets formatted in Pacific time on every fresh install. Any user not inAmerica/Los_Angelessees the reset time off by N hours (e.g. 9h in Europe/Rome), and it never self-corrects when they travel — macOS updates/etc/localtimeon timezone change, but the hardcoded setting overrides it.Root cause
An explicit default TZ is a footgun. A stale/wrong explicit value is just as broken as the UTC fallback the existing code comment already worries about — and worse, it silently wins over the real system clock.
Suggested fix
Ship
principal.timezone: ""(empty) by default so the resolver falls through to the OS clock, which self-corrects on travel. Treat an explicit IANA zone as opt-in for headless installs whose system TZ is UTC/wrong — not as the default.