From 1bc07a7ad044edf3764f001d4a32a3da18ddf042 Mon Sep 17 00:00:00 2001 From: Barely Removable Date: Tue, 8 Sep 2026 06:59:01 -0700 Subject: [PATCH] Wire up container timezone via /etc/localtime bind mount Container defaulted to UTC (no TZ configured), so calendar_run_time and the scraper's date-of-week logic didn't match the user's local clock. Uncomments the existing /etc/localtime mount and installs tzdata so the host's zoneinfo symlink actually resolves instead of silently falling back to UTC. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_013RbBoYm23muVyMZ18Ldqa6 --- CLAUDE.md | 19 +++++++++++++++++++ Dockerfile | 7 +++++++ docker-compose.yml | 4 ++-- 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 438fb6c..7813e62 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -126,6 +126,25 @@ volume-mounted `/data` inside the container) holds the calendar pull schedule — this is live user data, not deploy-managed. `.env` holds `HA_WEBHOOK_URL` and is server-only, gitignored, never committed. +**Container timezone (fixed 2026-09-08):** the container previously had no +timezone configured — `python:3.12-slim` defaults to UTC and the +`/etc/localtime` bind mount in `docker-compose.yml` was commented out — so +`calendar_run_time` (and the `datetime.now()` call in `scraper.py` that +picks which week to fetch) were evaluated against UTC, not the user's +local clock. This happened to be masked because Arizona (no DST) and +Pacific Daylight Time are both UTC-7 right now, but would have silently +drifted the actual fire time by an hour once PDT becomes PST in November. +Fixed by uncommenting the `/etc/localtime:/etc/localtime:ro` bind mount +and installing `tzdata` in the `Dockerfile` — without `tzdata`, the +host's `/etc/localtime` (typically a symlink into `/usr/share/zoneinfo/…`) +would dangle inside the container since that directory wouldn't exist, +silently falling back to UTC again. Found while investigating why the +first automatic Sunday calendar push after the 2026-09-03 pivot appeared +not to run — that specific miss turned out to be unrelated (the school's +Nutrislice menu was published empty for the whole week, so `_push_calendar` +correctly skipped every day), but this latent TZ bug surfaced during the +investigation and was worth fixing regardless. + **Migration note (2026-08-25):** this container originally used a Docker **named volume** (`lunch-notifier_lunch-settings`) instead of a bind mount. That meant Unraid's Appdata Backup plugin — which only knows about diff --git a/Dockerfile b/Dockerfile index efd7d0b..86797db 100644 --- a/Dockerfile +++ b/Dockerfile @@ -8,6 +8,13 @@ LABEL net.unraid.docker.icon="http://192.168.86.33:2323/icon.png" WORKDIR /app +# tzdata provides /usr/share/zoneinfo, which the host's bind-mounted +# /etc/localtime (docker-compose.yml) is typically a symlink into — without +# it present in the image, the symlink dangles and the container silently +# falls back to UTC. +RUN apt-get update && apt-get install -y --no-install-recommends tzdata \ + && rm -rf /var/lib/apt/lists/* + COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt diff --git a/docker-compose.yml b/docker-compose.yml index cfa485d..69f0b06 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -8,6 +8,6 @@ services: - "2323:2323" volumes: - ./data:/data - # Uncomment to share host timezone so RUN_TIME matches your local clock: - # - /etc/localtime:/etc/localtime:ro + # Shares host timezone so RUN_TIME matches your local clock: + - /etc/localtime:/etc/localtime:ro