Summary
docker/base-image/Dockerfile:12 sets ENV TZ=America/New_York, so every agent container runs on US Eastern local time regardless of where the instance or its operator is. The image's own timezone files disagree with it (/etc/localtime → Etc/UTC, /etc/timezone → Etc/UTC), so the container is internally inconsistent: date -u is right, everything local is 4–5 hours off.
Verified on v0.8.5 (b8cf94ca), trinity-agent-base:0.8.5.
Evidence
Baked into the image, not the deployment:
$ docker run --rm --entrypoint sh trinity-agent-base:0.8.5 -c 'echo "TZ=[$TZ]"; date +"%F %T %z"; ls -l /etc/localtime | tail -1'
TZ=[America/New_York]
2026-07-27 04:16:21 -0400
lrwxrwxrwx 1 root root 27 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
Inside a running agent, while real UTC is 08:16:21:
$ docker exec agent-p1-scout date
Mon Jul 27 04:16:50 EDT 2026
$ docker exec agent-p1-scout python3 -c "import datetime; print(datetime.datetime.now())"
2026-07-27 04:16:50.166431
Host, backend and agent all agree on UTC — only the agent's local time is shifted:
host UTC : 2026-07-27T08:16:06
backend : 2026-07-27T08:16:06
agent -u : 2026-07-27T08:16:06
agent : 2026-07-27T04:16:06 -0400
User-visible impact
1. Wrong timestamps in the UI. Agent-server file metadata is naive local time and is served as-is. A file written seconds earlier reports a time four hours in the past:
GET /api/agents/p1-scout/files
…"modified":"2026-07-27T04:06:58.549706" # no offset, actually EDT
GET /api/agents/p1-scout/credentials/status
".env":{"exists":true,"size":34,"modified":"2026-07-27T04:15:42.543220"}
Both are naive strings with no zone marker, so any consumer treating them as UTC (which the rest of the platform is — Invariant #16 mandates ISO-Z) renders "modified 4 hours ago" for a file that was just written. For an operator in UTC+3 the displayed skew is 7 hours.
2. Agents reason in the wrong timezone. Anything an agent does with local time — "today's report", daily rollups, "what time is it", deadline arithmetic, timestamps it writes into its own memory/output files — is on US Eastern. On a platform whose core loop is scheduled autonomous work, an agent that disagrees with both its operator and its own scheduler about what day it is will produce quietly wrong output. Schedules themselves are unaffected (they run backend-side with an explicit timezone field), which makes the mismatch harder to notice.
Note
This is not a regression I can attribute to 0.8.5 — the ENV TZ line looks long-standing. Raising it now because it is squarely in the "common things a person does" path (open the Files tab, ask an agent to write a dated note) and the fix is one line.
Suggested direction
Set ENV TZ=Etc/UTC in the base image so local == UTC and matches /etc/localtime, optionally allowing an operator override via an env var. Separately, the agent-server file/credential metadata would be more robust emitted as ISO-Z UTC (Invariant #16) rather than naive local strings, so a future TZ change cannot shift what the UI displays.
Summary
docker/base-image/Dockerfile:12setsENV TZ=America/New_York, so every agent container runs on US Eastern local time regardless of where the instance or its operator is. The image's own timezone files disagree with it (/etc/localtime→Etc/UTC,/etc/timezone→Etc/UTC), so the container is internally inconsistent:date -uis right, everything local is 4–5 hours off.Verified on v0.8.5 (
b8cf94ca),trinity-agent-base:0.8.5.Evidence
Baked into the image, not the deployment:
Inside a running agent, while real UTC is
08:16:21:Host, backend and agent all agree on UTC — only the agent's local time is shifted:
User-visible impact
1. Wrong timestamps in the UI. Agent-server file metadata is naive local time and is served as-is. A file written seconds earlier reports a time four hours in the past:
Both are naive strings with no zone marker, so any consumer treating them as UTC (which the rest of the platform is — Invariant #16 mandates ISO-Z) renders "modified 4 hours ago" for a file that was just written. For an operator in UTC+3 the displayed skew is 7 hours.
2. Agents reason in the wrong timezone. Anything an agent does with local time — "today's report", daily rollups, "what time is it", deadline arithmetic, timestamps it writes into its own memory/output files — is on US Eastern. On a platform whose core loop is scheduled autonomous work, an agent that disagrees with both its operator and its own scheduler about what day it is will produce quietly wrong output. Schedules themselves are unaffected (they run backend-side with an explicit
timezonefield), which makes the mismatch harder to notice.Note
This is not a regression I can attribute to 0.8.5 — the
ENV TZline looks long-standing. Raising it now because it is squarely in the "common things a person does" path (open the Files tab, ask an agent to write a dated note) and the fix is one line.Suggested direction
Set
ENV TZ=Etc/UTCin the base image so local == UTC and matches/etc/localtime, optionally allowing an operator override via an env var. Separately, the agent-server file/credential metadata would be more robust emitted as ISO-Z UTC (Invariant #16) rather than naive local strings, so a future TZ change cannot shift what the UI displays.