From c5451edfa381fba5c58e54883ec2abac60e39a88 Mon Sep 17 00:00:00 2001
From: Cal Corum <calcorum@users.noreply.github.com>
Date: Sun, 22 Feb 2026 16:41:31 -0600
Subject: [PATCH] =?UTF-8?q?store:=20Fix:=20UTC/CST=20timezone=20ambiguity?=
 =?UTF-8?q?=20in=20transaction=20freeze/thaw=20scheduling=20=E2=80=94=20ut?=
 =?UTF-8?q?ils/timezone.py?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...y-in-transaction-freezethaw-sche-4579c9.md | 63 +++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 graph/fixes/fix-utccst-timezone-ambiguity-in-transaction-freezethaw-sche-4579c9.md

diff --git a/graph/fixes/fix-utccst-timezone-ambiguity-in-transaction-freezethaw-sche-4579c9.md b/graph/fixes/fix-utccst-timezone-ambiguity-in-transaction-freezethaw-sche-4579c9.md
new file mode 100644
index 00000000000..d7eb624be06
--- /dev/null
+++ b/graph/fixes/fix-utccst-timezone-ambiguity-in-transaction-freezethaw-sche-4579c9.md
@@ -0,0 +1,63 @@
+---
+id: 4579c929-165e-4e96-a0f2-3604febf1734
+type: fix
+title: "Fix: UTC/CST timezone ambiguity in transaction freeze/thaw scheduling — utils/timezone.py"
+tags: [major-domo, timezone, transaction-freeze, production-fix, discord-bot, python, fix]
+importance: 0.75
+confidence: 0.8
+created: "2026-02-22T22:41:31.654639+00:00"
+updated: "2026-02-22T22:41:31.654639+00:00"
+---
+
+# Fix: UTC/CST Timezone Ambiguity in Transaction Freeze/Thaw Scheduling
+
+## Project
+major-domo / discord-app-v2
+
+## Problem
+Production container (`major-domo-discord-app-1` on Akamai) had ambiguous timezone config — `/etc/localtime` pointed to `Etc/UTC` but `date` reported CST. The transaction freeze/thaw task used `datetime.now()` (naive, relying on OS timezone), causing scheduling to fire at unpredictable wall-clock times.
+
+Additionally, `utils/logging.py` used `datetime.now().isoformat() + "Z"` — appending "Z" to a naive datetime is misleading (Z means UTC but the datetime had no tzinfo).
+
+## Root Cause
+- `datetime.now()` with no timezone argument produces a naive datetime, inheriting the OS/container timezone implicitly
+- Container timezone config was inconsistent between `/etc/localtime` and the OS `date` command output
+- Never rely on OS timezone in containerized environments
+
+## Fix
+1. Created `utils/timezone.py` with centralized timezone helpers:
+   ```python
+   from zoneinfo import ZoneInfo
+   from datetime import datetime, UTC
+
+   CHICAGO_TZ = ZoneInfo("America/Chicago")
+
+   def now_utc() -> datetime:
+       return datetime.now(UTC)
+
+   def now_chicago() -> datetime:
+       return datetime.now(CHICAGO_TZ)
+
+   def to_chicago(dt: datetime) -> datetime:
+       return dt.astimezone(CHICAGO_TZ)
+
+   def to_discord_timestamp(dt: datetime) -> str:
+       # Returns Discord <t:unix:R> format
+       ...
+   ```
+
+2. Changed `tasks/transaction_freeze.py` line 300:
+   - Before: `datetime.now()`
+   - After: `now_chicago()`
+
+3. Fixed `utils/logging.py` JSON timestamp:
+   - Before: `datetime.now().isoformat() + "Z"` (misleading Z on naive datetime)
+   - After: `datetime.now(UTC).isoformat()` (proper `+00:00` UTC suffix)
+
+## Verification
+JSON logs show datetime with `-06:00` CST offset and timestamp with `+00:00` UTC. Confirmed working in production after deploy.
+
+## References
+- PR #45 into `next-release`, merged to `main`
+- Closes Gitea issue #43
+- Key file: `utils/timezone.py` (new), `tasks/transaction_freeze.py`, `utils/logging.py`