Idea, not yet spec'd
Came up during grilling on the /hawk → /hawkbot slash-command rename (CONTEXT.md, ADR-0006) — logging it as a note to revisit later, not ready for implementation.
Current state: the operator manually sets the TZ environment variable in .env to the team's real IANA timezone. src/domain/calendar.ts relies on this ambient process timezone for all wall-clock math (midnight, "the day before," all-day date boundaries).
Idea: since Hawk Bot already has read access to the Team Meeting Calendar via the Google service account, it could read that calendar's own timeZone field (via calendars.get) instead of requiring the operator to hand-set TZ — one less manual deployment step.
Why it's not simple — calendar.ts currently depends on Date's local-time methods against the ambient process TZ, not an explicit timezone parameter. Auto-detecting from the calendar would mean either:
- mutating
process.env.TZ at boot from the fetched value (simple, but an odd runtime side effect, and wouldn't pick up a mid-life timezone change without a restart), or
- refactoring the wall-clock math in
calendar.ts (and weeklySummary.ts, which has similar formatting logic) to take timezone explicitly via a timezone-aware date library
Either way it also needs a fallback for when the Calendar API call fails or the calendar has no timeZone set.
Not scoped or prioritized — just don't want to lose the idea.
Idea, not yet spec'd
Came up during grilling on the
/hawk→/hawkbotslash-command rename (CONTEXT.md, ADR-0006) — logging it as a note to revisit later, not ready for implementation.Current state: the operator manually sets the
TZenvironment variable in.envto the team's real IANA timezone.src/domain/calendar.tsrelies on this ambient process timezone for all wall-clock math (midnight, "the day before," all-day date boundaries).Idea: since Hawk Bot already has read access to the Team Meeting Calendar via the Google service account, it could read that calendar's own
timeZonefield (viacalendars.get) instead of requiring the operator to hand-setTZ— one less manual deployment step.Why it's not simple —
calendar.tscurrently depends onDate's local-time methods against the ambient processTZ, not an explicit timezone parameter. Auto-detecting from the calendar would mean either:process.env.TZat boot from the fetched value (simple, but an odd runtime side effect, and wouldn't pick up a mid-life timezone change without a restart), orcalendar.ts(andweeklySummary.ts, which has similar formatting logic) to take timezone explicitly via a timezone-aware date libraryEither way it also needs a fallback for when the Calendar API call fails or the calendar has no
timeZoneset.Not scoped or prioritized — just don't want to lose the idea.