Skip to content

Feedback date today banned in forge scripts

Never use date.today() in any forge script. It returns the system-local date, which on UTC-hosted boxes (Console, some LXCs) means UTC date, not CT date. This caused food log entries made after 7pm CT to land on the next calendar day.

Always use: 

from datetime import datetime
import pytz
LOCAL_TZ = pytz.timezone('America/Chicago')
d = datetime.now(LOCAL_TZ).date()

Why: Console VM runs UTC; date.today() returned May 1 at 9:28pm CT because UTC had already rolled over. Three food log rows were misdated as a result.

How to apply: Any new or modified forge script that references 'today' must use datetime.now(LOCAL_TZ).date(). The eval harness should grep for bare date.today() calls and flag them as a doctrine violation. Add to LESSONS.md if not already present.

[auto-memory session b3843e07-58ca-46c1-802e-d72c90a04c97, confidence 0.92, mode direct]

Historical (auto-merged from feedback_food_log_utc_date_bug.md on 2026-05-01)

name: Food log date uses UTC not local timezone description: forge_food_log.py used date.today() (UTC) instead of local CT time, causing post-7pm entries to land on the wrong date type: feedback

Bug found and fixed in forge/scripts/forge_food_log.py: date.today() returns the system UTC date. Console VM runs UTC, so food entries logged after 7pm CT (midnight UTC) get stamped with tomorrow's date.

Fix: replace all date.today() calls with datetime.now(LOCAL_TZ).date() (five occurrences: lines ~80, 92, 197, 269, 324).

Why: Console is UTC, Justin is CT (UTC-5/UTC-6). Any time-sensitive script that writes date-stamped Notion rows must derive the date from local timezone, not system time.

How to apply: Any forge script that writes a date to Notion and runs on Console must use datetime.now(ZoneInfo('America/Chicago')).date() or equivalent. Never use date.today() for user-facing date context. Audit other pipelines (food log, workout log, habits) for the same pattern if they report wrong-day entries.

[auto-memory session b3843e07-58ca-46c1-802e-d72c90a04c97, confidence 0.88, mode direct]